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.


-----Original Message-----
From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Xavier Leroy
Sent: 22 April 2007 11:30
To: Jason Ganetsky
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Multiprocessor support in OCaml

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

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

_______________________________________________
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