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

[Sylvain Le Gall <sylvain@le-gall.net>]

On 24-03-2011, Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr> wrote:
> This is a multi-part message in MIME format.
> --------------010005060004040101060205
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> Hi,
>
>   Actually, I had a discussion two weeks ago with Xavier and Damien
> about this issue. There is some kind of agreement that the ocaml way of
> supporting multicore would be to have several runtimes running in the
> same process, in different threads. That way, the GC would still be
> mono-threaded, so almost no speed loss for mono-threaded programs (i.e.
> currently all OCaml programs ;-) ). There would be some kind of "fork"
> function, that would create a new thread running a function in a new
> heap, probably generated by a copy-on-need algorithm. 

That is a very good idea. I think this should be the less expensive
solution. I hope to see this implemented.

> The different threads would not share heap memory, but would be
> allowed to share structures outside of their heaps, probably for
> simple types like strings and int/float arrays (or using the Ancient
> library).
>

I think that you should basically left this "sharing" topic open.
Create communication channel and allow to send the address of a C
allocated structure (not managed by by the GC, of course). 


>   Now, there are still two problems:
> (1) We don't know yet how to implement that in a portable way. TLS
> (Thread-local storage) is only available on a few architectures. And not
> using TLS implies non-backward compatible changes to the FFI
> (Foreign-Functions Interface), i.e. all stub libraries would have to be
> rewritten.

Well, I have thought about this issue a lot during the last months.
Currently my best idea is to use a keyword "reentrant" for foreign
function (just as "noalloc").

If an external function is marked "reentrant", you pass an additional
parameters to the function, which is the context for doing allocation
and other things.

If an external function is not markd "reentrant", you acquire a general
lock and do as usual (or use TLS or whatever).

This "reentrant" keyword could be applied to a limited set of functions
of the OCaml runtime, to begin the benchmarks. Once it seems ok, you can
generalize the solution.

> (2) As Gerd pointed it, there are not so many programs that would
> benefit from that. 

Though I agree, I think a roadmap is a good point to show that INRIA
OCaml team is working on this issue. Today, even a half-working solution
for // will be better than nothing inside the INRIA OCaml core
distribution.

> So it is not currently on the top of our priority list, although I am
> planning to give it a try in the next months, at least for the TLS
> version.
>

I wish you good luck.

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall
Start an OCaml project here: http://forge.ocamlcore.org
OCaml blogs:                 http://planet.ocamlcore.org