Re: [Caml-list] OC4MC : OCaml for Multicore architectures

[Benjamin Canou <benjamin.canou@gmail.com>]

  Hi everyone,

And let's have a little prayer for Philippe who is now in bed, suffering 
from its head and hands because of his teammates letting him answer all 
the mail.
Just (half) kidding.

So,

Xavier Leroy a wrote (and probably described the work quite well) :
> what they did is an amazing hack [1]
> indeed --, but you need to keep in mind the difference between a
> proof-of-concept experiment and a product. 
By reading some messages in this thread I think we need to clarify again 
the context and goals of OC4MC.

One of our main goals for OC4MC is to serve as a parallel and shared 
memory low-level concurrency implementation, on top of which higher 
level research concurrency libraries and language extensions can be 
built. And as most of us agree, multicores, and soon manycores, are hard 
to program, in particular because of the memory bandwidth. So there 
probably are experiments to be done to help this at the language level, 
now that we have this parallel runtime. Moreover, and to answer a 
question that appeared in this thread, we provide our simple GC, but we 
separated the GC algorithm from the runtime, so OC4MC is also a 
low-level playground to experiment with your own GCs and choose the one 
you want to use at linking.

To sum up, let's see OC4MC as an experimentation platform that leverages 
some restrictions of OCaml, but of course neither as a drop-in 
replacement for the official distribution nor as the future of OCaml. We 
do not claim that the ideal solution to bring shared memory parallelism 
to OCaml is, as OC4MC does, only to replace the runtime (and that INRIA 
can just replace the official runtime by our hacked one).  However, from 
a pragmatic (and optimistic) point of view, the modifications to the 
compiler have been kept very lightweight, yet sufficient to break binary 
compatibility. So if the excitement continues around OC4MC as in this 
thread, maybe these modifications could be integrated into the 
distribution since they really do not touch the core of the compiler and 
cannot cause a lot of maintenance overhead.

I will add that we did not made this experiment to beat F# or python's 
hashtables, so I will not comment on that here. The point about 
performance is that it should be *predictable*.  We now have rewritten 
and debugged most of the memory related behaviors present in the 
original runtime in a more generic (and OC4MC friendly) way to achieve 
this, and if it's not the case for some particular cases, we'll be glad 
to (try to) fix these bugs.

On the maintenance side, as Philippe said, we already have some half 
working version with ocaml 3.11.x, but partly because of the changes 
made to the native runtime in this release and partly because of [1], 
porting the patch is not trivial.

Cheers and have fun experimenting with OC4MC (so it will compensate the 
amount of debugging we spent on it ;-) ).
  Benjamin.