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
OC4MC : OCaml for Multicore architectures
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-09-24 (13:00)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures
On Thursday 24 September 2009 13:14:35 Philippe Wang wrote:
> On Thu, Sep 24, 2009 at 3:47 AM, Jon Harrop <jon@ffconsultancy.com> 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&copy 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&copy 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).


Dr Jon Harrop, Flying Frog Consultancy Ltd.