From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 707A8BBAF for ; Sun, 13 Jul 2008 05:17:42 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFAMcQeUjQccgFY2dsb2JhbACBWpBIFwUCBRmVWQ X-IronPort-AV: E=Sophos;i="4.30,352,1212357600"; d="scan'208";a="27274156" Received: from lax-green-bigip-5.dreamhost.com (HELO looneymail-a5.g.dreamhost.com) ([208.113.200.5]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Jul 2008 05:17:41 +0200 Received: from Smokejumper-MBP.local (c-71-63-174-117.hsd1.mn.comcast.net [71.63.174.117]) by looneymail-a5.g.dreamhost.com (Postfix) with ESMTP id C7C21122CE8 for ; Sat, 12 Jul 2008 20:17:38 -0700 (PDT) Message-ID: <487973D2.3040909@fischerventure.com> Date: Sat, 12 Jul 2008 22:17:38 -0500 From: Robert Fischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: caml-list Subject: Code Mobility [was Re: thousands of CPU cores] References: <1215732802.48769c4277e80@webmail.in-berlin.de> <200807110950.52327.jon@ffconsultancy.com> In-Reply-To: <200807110950.52327.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 parallelism:01 bandel:01 in-berlin:01 pae:98 threads:01 threads:01 wrote:01 wrote:01 unix:01 oliver:01 oliver:01 abstract:01 arbitrary:02 arbitrary:02 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 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. >