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
thousands of CPU cores
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-07-13 (03:17)
From: Robert Fischer <robert@f...>
Subject: Code Mobility [was Re: thousands of CPU cores]
One thing being left out on this conversation is code mobility.

If I want to execute an arbitrary piece of code in parallel, organizing a distributed message
passing system to accomplish that is nontrivial.

Since we're in a functional language, a key piece of our functionality is the ability to abstract
out what code we're executing in new and exciting ways -- CPS being a classic example of this.
However, if I'm in a multi-process system, my capability of doing CPS is exceedingly limited,
because OCaml isn't the kind of language where you can just schlep around arbitrary code.

So, until we have code mobility, there is a huge win of multithreaded code over multiprocess code.

Problems which can be simply broken down at a nice, obvious breakpoint work just fine in a
multiprocess style.  But if I want implicit or radical parallelism -- if I want the ability to go
"take this function -- whatever it is -- and execute it in parallel and give me back the result",
then I'm going to need truly parallel threads.  And that kind of stunts is exactly the kind of thing
which is going to make your code leverage kilocores effectively.

~~ Robert.

Jon Harrop wrote:
> On Friday 11 July 2008 07:26:44 Sylvain Le Gall wrote:
>> On 10-07-2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
>>> Using multi-processes instead of multi-threads is the
>>> usual way on Unix, and it has a lot of advantages.
>>> Threads-apologetes often say, threads are the ultimative
>>> technology... but processes have the advantage of encapsulation
>>> of the wohole environment of the program.
>> There is also the fact that using multi process allow you to go further
>> than the memory limit per process...
> Yes.
>> (3GB for Linux/
> Is that for 32-bit Linux?
>> 1GB for Windows)...  
> 32-bit Windows XP has a 2Gb default process memory limit:
>   http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
>   http://msdn.microsoft.com/en-us/library/aa366778.aspx
> 32-bit Windows Server can be increased to 3Gb.
> However, any serious power users will already be on 64-bit where these limits 
> have been relegated to quaint stories your grandpa will tell you.