Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Philippe Wang <philippe.wang@lip6.fr>
To: caml-list@inria.fr
Cc: Philippe Wang <Philippe.Wang@lip6.fr>
Subject: Re: [Caml-list] "ok with parallel threads" GC (aka ocaml for multicore)
Date: Thu, 23 Apr 2009 18:49:11 +0200	[thread overview]
Message-ID: <BB1D38C3-2253-4BE8-885D-A056AF3DDDAD@lip6.fr> (raw)
In-Reply-To: <5409216D-4094-424B-BEEE-3AC3701A87DD@lip6.fr>

> On Sat, Apr 18, 2009 at 1:05 AM, forum@x9c.fr <forum@x9c.fr> wrote:
>     I was indeed mostly worried with the runtime itself. I wanted to  
> have a fully reentrant runtime for the OCaml-Java
>     project (to be able to execute several programs in the very same  
> JVM) and remember that it implied primitives
>     from "compare.c", "hash.c", "intern.c" and "extern.c" among  
> others to be written differently for this purpose.

Indeed. We have made them reentrant but we haven't made much stress  
testing on that.
Reentrance on those are not free (they have a cost), and the way we  
chose is the "simplest or quickest way".

>     Out of curiosity: you state that your GC is of "stop-the-world"  
> nature, what about finalizers ?
>     Are they executed by the GC thread when the world is stopped or  
> concurrently with
>     application threads ?
>     Not sure this question really matters, just curious (I mean, it  
> is doubtful that one would write finalizers with
>     a long execution time).

Finalizers are supposed to be called by the thread that does the  
garbage collection, so there is no concurrency with finalizers as the  
rest of the world is meant to be stopped when garbage collecting.
(Our garbage collector does not try to be as smart as the original one  
on many many things)

By the way, we are late on writing the documentation for our future  
release...
but we have just implemented a (simple) experimental growing heap.

Here is a quote from wikipedia (http://en.wikipedia.org/wiki/Speedup):
<<
Sometimes a speedup of more than N when using N processors is observed  
in parallel computing, which is called super linear speedup. Super  
linear speedup rarely happens and often confuses beginners, who  
believe the theoretical maximum speedup should be N when N processors  
are used.
 >>
Well, we *have* observed that on a matrix multiplication :-)

--
Philippe Wang
  Philippe.Wang@lip6.fr
  http://www-apr.lip6.fr/~pwang/


      parent reply	other threads:[~2009-04-23 16:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10 17:04 Philippe Wang
2009-04-10 20:52 ` [Caml-list] " Jon Harrop
2009-04-10 23:20 ` Jerome Benoit
     [not found] ` <BB3C091F-3BE9-4883-A7CF-9D672CDDF829@x9c.fr>
2009-04-14 10:21   ` Philippe Wang
2009-04-14 14:18     ` xclerc
2009-04-16  9:45     ` Philippe Wang
2009-04-17 22:15       ` Philippe Wang
2009-04-17 22:20         ` Joel Reymont
2009-04-17 22:29           ` Philippe Wang
2009-04-17 23:05         ` forum
2009-04-23 16:49         ` Philippe Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BB1D38C3-2253-4BE8-885D-A056AF3DDDAD@lip6.fr \
    --to=philippe.wang@lip6.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox