Re: [Caml-list] Efficient OCaml multicore -- roadmap?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Donnerstag, den 24.03.2011, 09:44 -0400 schrieb Alexy Khrabrov:
> Where does the OCaml team stand on the multicore issues?  A year or so ago, when there was a prototype parallel GC implementation, IIRC, Xavier said it has to be done right.  So what are the official plans and the status of integrating what volunteers had done?
> 
> WIth Scala having a robust actors model and AKKA kernel, and Clojure built around efficient shared memory concurrency with agents and references and STM, and Haskell also really parallel, OCaml is lacking behind.  Furthermore, F# builds on strongly parallel .NET, overcoming granddaddy.  With multicores common even in laptops and iPads, we need an efficient  multicore OCaml!  Due to the model different from Haskell or Scala and Clojure, now all on github, OCaml is both more stable and also is slower to advance -- what do folks think about this situation?  How do you do shared memory parallelism now?

I'm a bit reluctant to answering to this at all, because there is a big
misunderstanding in the world about what parallelism is good for. Some
people think it is a technique for doing micro optimizations in their
code (i.e. parallelize some inner loops). Questions about "shared memory
concurrency" often go into this direction because existing code can
profit from it. Although there is nothing wrong in principal about this,
one should be very aware that the usefulness is very limited - often
only code speedups of a few percent of the total runtime can be
achieved, and it is often restricted to two cores. If you look at
programs that are designed for parallelism, the whole story is a
completely different one, though.

So, here is my answer to your latter question: I've started a library
for using independent processes as workers that can communicate via
explicit shared memory (see
https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmulticore/, and https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/examples/multicore/chameneos.ml for a coding sample). This seems at least to be a solution in the Unix world for coarse-grained parallelism that is not dominated by the communication overhead between the processes. Available features:

- manage worker processes
- the processes can use files, shared memory, and semaphores
- processes can communicate to each other by sending messages to
  "camlboxes". By tricky implementation, there is only overhead for 
  serialization but not deserialization which makes message passing
  really fast

Of course, this is all very experimental. At least it demonstrates that
exploiting shared memory between independent processes is possible. For
getting a real programming environment, one needs to put more effort
into this, though, especially we would need data structures that can
live in shared memory (e.g. hashtables).

The resulting programming model is of course not the usual
multi-threading model. In particular, values are not automatically put
into shared memory. This has to be explicitly managed. IMHO, this is not
a weakness, but rather a strong point (and not everybody will understand
this - it's a somehow comparable to banning "goto" from higher-level
languages). It also means that you cannot use parallelism for doing
micro optimizations - the whole program has to be re-designed.

Generally, I'd say there is right now no perfect solution to the
problem. As language developer, you have to foresee future hardware to
some degree. When more and more cores are added, the characteristics of
the hardware will gradually shift from SMP to NUMA, and the more it
does, message passing techniques will become more attractive.

I'd like to see Ocaml doing here well. Let the others focus on SMP
architectures (which will, at a certain point of hardware development,
only be found in laptops but not in real compute hardware).

Gerd

> 
> Cheers,
> Alexy
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------