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

[Dario Teixeira <darioteixeira@yahoo.com>]

Hi,

> 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.

Thanks for the clarification.  While not detracting from your work (which
I think is very interesting and valuable), for me single-thread performance
is still paramount.  I am working in a domain (doing backend web application
programming using the Ocsigen framework) where multi-threaded parallelism
is a bit silly, since you can get much better performance and design
simplicity by running multiple independent servers (one for each core).
Each server runs multiple concurrent Lwt-threads (a cooperative form of
green threads) to make sure the CPU is always busy and not waiting on I/O.

This solution has the advantage of requiring no process context-switching
within each server, while still maximising CPU utilisation.  And I suspect
there are many other fields where a similar approach could be used advantageously
instead of thread-based parallelism.


> 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...

Again, it's a question of whether the cost justifies the benefits.
Personally, I'm in the camp that would rather see improvements to
the type system (like native GADTS!)...

Anyway, keep us appraised of your work.  It's very welcome.

Best regards,
Dario Teixeira