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/
prev 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