caml-list - the Caml user's mailing list
 help / Atom feed
From: Don Syme <>
To: Xavier Leroy <>, Jason Ganetsky <>
Cc: "" <>
Subject: RE: [Caml-list] Multiprocessor support in OCaml
Date: Sun, 22 Apr 2007 12:55:51 +0100
Message-ID: <> (raw)
In-Reply-To: <>

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


P.S. I've only used this technique on Windows.

-----Original Message-----
From: [] On Behalf Of Xavier Leroy
Sent: 22 April 2007 11:30
To: Jason Ganetsky
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:
Beginner's list:
Bug reports:

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-22  7:42 Jason Ganetsky
2007-04-22  8:44 ` [Caml-list] " Richard Jones
2007-04-22 10:30 ` Xavier Leroy
2007-04-22 11:55   ` Don Syme [this message]
2007-04-22 10:58 ` Erik de Castro Lopo
2007-04-22 13:29   ` Jon Harrop
2007-04-22 17:31 ` Zheng Li
     [not found]   ` <>
2007-04-22 17:52     ` [Caml-list] " Jason Ganetsky
2007-04-23  8:10       ` Richard Jones

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror

AGPL code for this site: git clone public-inbox