From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 1F1C9BC69 for ; Wed, 30 May 2007 11:56:33 +0200 (CEST) Received: from oden.vtab.com (dns.vtab.com [62.20.90.195]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4U9uWl2018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 May 2007 11:56:32 +0200 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 06F0926EEF1; Wed, 30 May 2007 11:56:32 +0200 (CEST) Received: from virtutech.se (alfredo.hq.vtech [10.0.0.52]) by oden.vtab.com (Postfix) with ESMTP id E820026EEEF; Wed, 30 May 2007 11:56:31 +0200 (CEST) Received: (from mattias@localhost) by virtutech.se (8.11.6/8.11.6) id l4U9uV517133; Wed, 30 May 2007 11:56:31 +0200 Date: Wed, 30 May 2007 11:56:31 +0200 Message-Id: <200705300956.l4U9uV517133@virtutech.se> From: "=?iso-8859-1?q?Mattias_Engdeg=E5rd?=" To: jon@ffconsultancy.com Cc: caml-list@yquem.inria.fr In-reply-to: <200705300954.32784.jon@ffconsultancy.com> (message from Jon Harrop on Wed, 30 May 2007 09:54:32 +0100) Subject: Re: [Caml-list] Faking concurrency using Unix forks and pipes Content-Type: text/plain; charset=iso-8859-1 References: <200705300442.59906.jon@ffconsultancy.com> <200705300902.06760.jon@ffconsultancy.com> <20070530181300.d4179bca.mle+ocaml@mega-nerd.com> <200705300954.32784.jon@ffconsultancy.com> X-Virus-Scanned: ClamAV using ClamSMTP X-j-chkmail-Score: MSGID : 465D4A50.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 465D4A50.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 mattias:01 forks:01 marshalling:01 traversing:01 threads:01 read-only:01 heap:01 heap:01 unix:01 caml-list:01 gcs:01 data:02 concurrency:02 deallocate:03 >> How much does a concurrent GC actually buy in comparison to >> multiple processes each with their own GC and a robust way >> of passing data between processes? > >1. Shared memory and locks should be much faster for synchronization than >marshalling between processes. > >2. Forking results in multiple GCs redundantly traversing the same heap and, >worst case, it may end up copying the entire heap in the child process in >order to deallocate it. 3. Cores on the same chip often share at least one cache level, and the same is trivially true for threads in the same core. In software-speak, this means that processes should share the read-only part of their working set as much as possible.