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.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 8F107BBAF for ; Thu, 24 Sep 2009 15:00:45 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUBALcJu0rUnwdkkWdsb2JhbACCIZhgAQEBAQcNCgcTBLsyhBsFgVg X-IronPort-AV: E=Sophos;i="4.44,445,1249250400"; d="scan'208";a="47197037" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Sep 2009 15:00:45 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFAPMJu0rUnw6T/2dsb2JhbACCIdROhBsFgVg Received: from ptb-relay03.plus.net ([212.159.14.147]) by relay.pcl-ipout02.plus.net with ESMTP; 24 Sep 2009 14:00:44 +0100 Received: from [87.114.87.187] (helo=leper.local) by ptb-relay03.plus.net with esmtp (Exim) id 1MqnwC-0003lU-8N for caml-list@yquem.inria.fr; Thu, 24 Sep 2009 14:00:44 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures Date: Thu, 24 Sep 2009 14:11:58 +0100 User-Agent: KMail/1.9.9 References: <200909240247.17560.jon@ffconsultancy.com> <4d1b2df20909240514t1ea2d04hd87ba675e4cc929@mail.gmail.com> In-Reply-To: <4d1b2df20909240514t1ea2d04hd87ba675e4cc929@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909241411.58823.jon@ffconsultancy.com> X-Plusnet-Relay: 652723bf6042b74ef988f1ee911dabda X-Spam: no; 0.00; ocaml:01 deques:01 arrays:01 pointer:01 ocaml's:01 bindings:01 ocaml:01 2009:98 2009:98 nursery:98 frog:98 threads:01 threads:01 wrote:01 wrote:01 On Thursday 24 September 2009 13:14:35 Philippe Wang wrote: > On Thu, Sep 24, 2009 at 3:47 AM, Jon Harrop wrote: > > Following your advice, it seems to work perfectly now: > > > :-) > : > > Wow! 2.6x faster on 2 cores is good. ;-) > > your machine is more generous than ours (which is Intel, not AMD) :-) Yes. I don't know why AMD are so much better at this but I have seen it several times now. > > That's a really fantastic piece of work. I'll do my best to study it and > > write literature about it. May I ask, can you give a rough overview of > > the design? For example, is there a separate nursery per thread so each > > thread can allocate a certain amount before incurring a global pause? Do > > you have any ideas for libraries built on top of this, such as a task > > parallel library using work-stealing deques? > > A few words on the GC's design (that uses stop© algorithm several > times) : > > Heaps : > - a set of pages are used to give threads the possibility to allocate > memory without interfering with other threads, such as there is no > mutex locking at local memory allocation. Each thread borns with an > empty page, when it's full, the thread takes another one. > - a big heap is shared between all, there is a mutex over it to > prevent parallel memory allocation into this one. > > Collection : > - when there are no pages left, a collection stops-the-world and > copies living values (of the pages) to the shared heap > - when the shared heap is full, a collection stops-the-world and > copies all living values (pages+shared heap) to a new shared heap > (which can be grow if need be) Ok, so this is stop© GC with per-thread nurseries/gen0. Are values such as float arrays copied in their entirety or are they allocated outside the shared heap and only a pointer to them is copied? Is the copy operation parallelized? Is there a write barrier but no read barrier? If so, what exactly does the write barrier do? > Special operations : > - if there is a blocking operation (e.g. mutex lock or I/O operation), > the mechanism is roughly the same as original INRIA OCaml's : it tells > the GC that there is no need to stop it when stopping the world. Can users mark external calls in their bindings as blocking so the GC will treat them appropriately? > - if there is a thread with no allocation and no blocking operation, > the behaviur is the same as INRIA OCaml. > > The number of pages, the size of a page, and the size of the shared > heap can be changed before running a program by setting some > environment variables (cf. last lines README file included in the > distribution package). Great! -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e