From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C1B7DBCAE for ; Fri, 24 Jun 2005 10:51:59 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5O8pxAe016372 for ; Fri, 24 Jun 2005 10:51:59 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA15181 for ; Fri, 24 Jun 2005 10:51:59 +0200 (MET DST) Received: from m14s26.vip-server.net (m14s26.vip-server.net [193.138.181.188]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5O8pw32016366 for ; Fri, 24 Jun 2005 10:51:58 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by m14s26.vip-server.net (Postfix) with ESMTP id E75B194BCE; Fri, 24 Jun 2005 10:43:19 +0200 (CEST) Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future? From: Jean-Marie Gaillourdet To: jtbryant@valdosta.edu Cc: caml-list@inria.fr In-Reply-To: <1119547256.4675.12.camel@starlight.valdosta.edu> References: <3d13dcfc05062300215e4be9ee@mail.gmail.com> <1119547256.4675.12.camel@starlight.valdosta.edu> Content-Type: text/plain Date: Fri, 24 Jun 2005 10:52:06 +0200 Message-Id: <1119603126.8485.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42BBC9AF.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42BBC9AE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml's:01 donnerstag:01 heap:01 threads:01 allocations:01 synchronized:01 garbage:01 threads:01 garbage:01 ...:98 constructor:01 tuple:02 functional:02 guess:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Hi, Am Donnerstag, den 23.06.2005, 13:20 -0400 schrieb Jonathan_T_Bryant: > As far as the GC, am I'm just kinda throwing this out off the cuff, but > couldn't the heap be a shared memory segment that all threads attach to, > thereby allowing easier collection on multiple processors. All > allocations could be synchronized (via some kind of semaphore) and could > be locked only during a collection. I know this is a lot harder than > that, but, like I said, it's just an idea... I am not a garbage collector specialist, too. But I guess it is much harder than this. Your idea implies that every allocation requires to obtain a lock. How often do you allocate memory in a functional programming language? Quite often, I guess. Every simple tuple, every constructor application and so on. So you would synchronize all threads very often. Additionally, during every collection phase, all other cpus have to wait for the garbage collector. I am pretty sure, that this would not scale very far. Sorry ;-) Best Regards, Jean-Marie