Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[ANN] coThreads 0.10
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-09-17 (22:35)
From: Zheng Li <li@p...>
Subject: Re: [ANN] coThreads 0.10


skaller <> writes:
> Yes but what I'm getting at is the claim of multi-processing,
> which Ocaml 3.10 at least cannot do. If you run Ocaml on a multi-core
> machine, even if you have 8 cores and 8 threads, one on each core,
> only one will ever run at once, so there is no performance gain.
> In fact, it will be slower than a single core.
> If you are *enforcing* message passing and using separate processes
> instead of threads, then 8 processes will run in parallel on 8 cores,
> and you'll get roughly 8 times speedup.
Yes, you are right. The process engine is implemented with process. That's how
it can speedup and that's why it's called ``process engine''.  

> So I'm not asking about how to ensure the code is consistent
> over the various models, but rather how you can get ANY genuine
> concurrency WITHOUT using message passing and processes
> (in which case the networking model should be easy to implement)
I'm sorry if the document misleadingly made you think it get speedup without
using process and message passing. Threads and related tools is just the
abstract interface on which all engines agree, they implement it with various
facilities from VM threads, system threads to  process or independent programs.

> Whether you explicitly send messages or use transactional memory
> or whatever to wrap the message passing isn't the question:
> I can see how that can work. However note, the message passing
> has to be used for immutable values too, if the threads are
> represented by processes in separate address spaces.
For immutable value, it's not different from the traditional threads, at least
from the library users' point of view: if a variable is already inside the
scope of a threads (i.e. it's global and created before launching the thread),
there is no necessity to message passing it; if not, you should anyway do it
explicitly even with the traditional threads.

Zheng Li