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

[Philippe Wang <philippe.wang.lists@gmail.com>]

On Thu, Sep 24, 2009 at 4:11 PM, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> Hi,
>
> Cheers for the work you guys put into this project!  And I'd like to join
> the crowd that has questions, if I may:
>
> a) If I understand correctly, part of prerequisites for implementing the
>   new GC was cleaning up the excessive use of imperative constructs in
>   the compiler's tree.  Will the new tree be also more amenable to the
>   implementation of new language constructs such as GADTs?

Nope...
We wanted not to touch the code generator (or any other part of the
compiler). Eventually, we had to modify a very little bit the code
generator so that it does not compact too much the generated code.
That meant changing less than 10 lines of ml code.

> b) Could you quantify the performance penalty (if any) of using the new GC
>   in a single-thread context?  And should this penalty be significant, are
>   there provisions for a compile-time choice of which GC to use?

Very few programs that are not written with multicore in mind would
not be penalized.
I mean our GC is much much dumber than INRIA OCaml's one.
Our goal was to show it was possible to have good performance with
multicores for OCaml.
Maybe someday we'll find some time to optimize the GC, but it's likely
not very soon.

> c) Is there an understanding between you and the folks at INRIA concerning
>   the eventual merging of this code into the mainline tree?

Almost same answer as the previous one.
We have shown that it's possible to enjoy multicore for performance.
The changes over the whole runtime library are not easy to merge into
mainstream.

It is very important to know this : the runtime library is written in
C (and a little part is in ASM in order to have better performance...
but mainly because of the "foreign function interface" so there is no
way to ignore it). Its type system really sucks (comparing to
OCaml's). When you change a very little part, it will tell you that
you were wrong, but not with a hard-to-understand type error message :
it will be some tricky dirty segmentation fault, which can sometimes
that days or weeks, even months, to take down.


I guess that if INRIA decides to implement parallel threads
capability, they will have to make the runtime library ready (clean up
some global variables, tidy the code like remove compatibility.h and
such stuff) before thinking about the GC. This could take some time,
because it's not good to break everything at once. Then, if they have
finished this step, I would be confident that they could integrate an
awesome GC.
But that's only my personal opinion...

Oh, why they wouldn't take OC4MC? ... If I were them, I wouldn't. We
have probably broken some stuff such as Weak or Lazy, so there is no
chance to bootstrap with OC4MC. Well, I mean that it's better to
change INRIA's OCaml with all the lessons learnt than to try to fix
OC4MC such that it's fully compatible with latest version of INRIA
OCaml.

-- 
Philippe Wang
   mail@philippewang.info