[Caml-list] Multiprocessor support in OCaml
Jason Ganetsky
I'm new to this list, and new to OCaml (although, have some experience with
SML).
Anyway, I have recently written an OCaml thread pool implementation, on top
of the Thread and Event modules. I did this for the purpose of exploiting an
SMP system I have, and was a disappointed to read today that OCaml doesn't
support multiprocessor systems.
I played around with it a little, and discovered that by liberally calling
Thread.yield, I do cajole my threads into running on multiple processors. Is
this behavior normal, or have I discovered a problem with the Thread module?
I'm certainly happy that I can get it to use my SMP... but I will stop it at
once if you tell me that this is unsafe.
-Jason
Richard Jones
> I'm new to this list, and new to OCaml (although, have some experience with
> SML).
There's a beginner's list:
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Anyway, I have recently written an OCaml thread pool implementation, on top
> of the Thread and Event modules. I did this for the purpose of exploiting an
> SMP system I have, and was a disappointed to read today that OCaml doesn't
> support multiprocessor systems.
>
> I played around with it a little, and discovered that by liberally calling
> Thread.yield, I do cajole my threads into running on multiple processors. Is
> this behavior normal, or have I discovered a problem with the Thread module?
> I'm certainly happy that I can get it to use my SMP... but I will stop it at
> once if you tell me that this is unsafe.
The garbage collector doesn't support concurrency, so there's a big
global lock around all OCaml code.
http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Xavier Leroy
> top of the Thread and Event modules. I did this for the purpose of
> exploiting an SMP system I have, and was a disappointed to read today
> that OCaml doesn't support multiprocessor systems.
You are correct that OCaml *threads* do not exploit multiprocessing.
Basically, only one OCaml thread can run at a time.
You can still get parallelism in several ways. First, external C
libraries called from OCaml can run in parallel with OCaml code
provided the OCaml/C interface for these libraries makes uses of the
"blocking section" mechanism. Second, process-level parallelism works
very well with programs written in message-passing style, using e.g.
OcamlMPI or OCamlP3L.
> I played around with it a little, and discovered that by liberally
> calling Thread.yield, I do cajole my threads into running on multiple
> processors.
This is an illusion. Thread.yield gives more opportunities to the OS
scheduler to reschedule a Caml thread on a different processor, but
you're not gaining parallelism this way and you might actually lose
performance (because of cache ping-pong effects and the like).
- Xavier Leroy
Erik de Castro Lopo
> Hi all,
>
> I'm new to this list, and new to OCaml (although, have some experience with
> SML).
>
> Anyway, I have recently written an OCaml thread pool implementation, on top
> of the Thread and Event modules. I did this for the purpose of exploiting an
> SMP system I have, and was a disappointed to read today that OCaml doesn't
> support multiprocessor systems.
For real multi-procesor parallelism, have a look at this:
http://www.pps.jussieu.fr/~dicosmo/ocamlp3l/
Haven't tried it myself, but its on my todo list.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"life is too long to be an expert at harmful things, including
such evilness as C++ and perl." -- Erik Naggum
Don Syme
Just to mention there is a way of getting multiple concurrently executing OCaml threads in a program, which I discovered a while back: you can statically link multiple independent copies of the OCaml runtime, each into its own DLL (on Windows). This allows multiple independent OCaml threads to run concurrently.
I presume this technique works well enough for SMP up to 2-4 processors, though have never done any serious performance testing.
The OCaml programs must not, of course, trade OCaml values, but can communicate in-process by other means (e.g. shared C memory or some other message passing technique).
Regards,
Don
P.S. I've only used this technique on Windows.
Jon Harrop
> For real multi-procesor parallelism, have a look at this:
>
> http://www.pps.jussieu.fr/~dicosmo/ocamlp3l/
>
> Haven't tried it myself, but its on my todo list.
Has anyone tries this? Got any demos? I've been meaning to look at it for a
while as well... :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e
Zheng Li
Hi,
I'm working on a process back-end of STM library. It's now supported by Google
SOC and expected to release after the summer (and maybe earlier). With it, you
will be able to do shared-memory (supposing that's the style your want)
parallel programming based on processes, which in turn gives you speedup.
If interested, you can have a taste first through the (vm)thread back-end
currently available (check my homepage below), though it won't really speed up
your program because of the well-known global lock of OCaml threads.
"Jason Ganetsky" <jason.g...@gmail.com> writes:
> Hi all,
> I'm new to this list, and new to OCaml (although, have some experience with
> SML).Anyway, I have recently written an OCaml thread pool implementation, on
> top of the Thread and Event modules. I did this for the purpose of exploiting
> an SMP system I have, and was a disappointed to read today that OCaml doesn't
> support multiprocessor systems.
>
> -Jason
--
Zheng Li
http://www.pps.jussieu.fr/~li
Jason Ganetsky
>
> Well, the solution I'm going for now is to load all my data up, call
> Gc.Compact(), and then fork off child processes. The workload that I'm
> parallelizing is read-only... so I think this will work well with Linux
> copy-on-write forking.
Richard Jones
>
>Well, the solution I'm going for now is to load all my data up, call
>Gc.Compact(), and then fork off child processes. The workload that I'm
>parallelizing is read-only... so I think this will work well with Linux
>copy-on-write forking.
You might also want to look at the Ancient library
(http://merjis.com/developers/ancient) which will allow you to share
data read-only between unrelated processes, backed by a file.
Rich.
--
Richard Jones
Red Hat
_______________________________________________