English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
ocaml for embedding
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-07-20 (15:02)
From: Eray Ozkural <examachine@g...>
Subject: Re: [Caml-list] ocaml for embedding
On Tue, Jul 20, 2010 at 3:36 AM, Eray Ozkural <examachine@gmail.com> wrote:

> On Mon, Jul 12, 2010 at 4:19 PM, Gaspard Bucher <gaspard@teti.ch> wrote:
>>  Just a final question on the topic: has JoCaml anything to do with
>> this concurrency (shared memory) question ?
> It seems to me that it can be implemented for a shared memory system. Why
> not? But it's been designed with distributed memory in mind. So, I suppose
> writing to shared memory could be slow. It'd be sort of like implementing
> synchronization on top of a message passing system. Although I can see that
> reading is OK.

On second thought it's not so clear how reads could be efficient. I'd
assumed that somehow messages could be sent without making a separate copy
of the data, so in principle we could perform the reads just as fast.
Interesting question, though, thanks Gaspard. Now I realized it's not so
clear and I apologize for that mistake, because that would be only valid for
immutable data structures. And I suppose with immutable data structures you
get only part of the advantages of shared memory, right? What good is a
parallel RAM if it doesn't support concurrent writes?

So, I think, no matter what kind of abstract concurrency primitives you
provide, you'd still need proper shared memory + threads for the low-level
programmer. Or as I said, you can also get speedup using MPI, but usually
that's not the best speedup you are going to get because a) you can't avoid
copying huge messages across processes b) mpi implementation may have too
much penalty for finer-grain code, i.e. latency will become significant. I
think MPI or these high-level concurrent processes would be good on shared
memory if the problem is embarrasingly parallel. But as we all know only a
small minority of problems turn out to be that easy to solve in parallel!

At any rate, I'm sure we'll have it one day, I'm keeping my fingers crossed


Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://myspace.com/arizanesil http://myspace.com/malfunct