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.9 required=5.0 tests=HTML_10_20,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C5269BBCA for ; Sat, 19 Apr 2008 10:46:55 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMGAGJOCUjAXQIn/2dsb2JhbACCQTejfIRK X-IronPort-AV: E=Sophos;i="4.25,682,1199660400"; d="scan'208";a="9761676" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Apr 2008 10:46:55 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m3J8ktUa005634 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sat, 19 Apr 2008 10:46:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAEhOCUjRVciodWdsb2JhbACCQTeObAEMAwQHBxSUWIRK X-IronPort-AV: E=Sophos;i="4.25,682,1199660400"; d="scan'208";a="25187157" Received: from wf-out-1314.google.com ([209.85.200.168]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Apr 2008 10:46:54 +0200 Received: by wf-out-1314.google.com with SMTP id 26so1011337wfd.0 for ; Sat, 19 Apr 2008 01:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=kxueCOb/QPsK1JI7IdvISKsiPEtzkQV8LSjCVWBbL8E=; b=PzY1ryuFOQknVa03vleA0PqDjd6CjUlq8haapUzOHKSD/Ch7WvZ7HDbVcUSpGlkJwsvuZO/wNh4wMqMAmluVNLfPRx8N9DUIdU9LC8gZwyZ5nLGgRuQ21vgL/Kn3zv72ZHeFGYf+p9IWd66U0m4xtcBe0j8UaXYdi0PAhwEM44g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mTWpbzAbSSdQbFlaSWF/WUI4LwP7haLqu4ARFDdX/tyE8oJG5OABhB04l1qw2kBRqN9XhbiAQVTwFgegg5AkNb/BEYgPQKZCwOF35aYf6gd1iQ62v6+Jc+ac0FSmLdbRmhlAzj4YS7SzKnmNkTV/11VNA/lYisWAbq1Klo5cmLw= Received: by 10.142.54.8 with SMTP id c8mr943196wfa.318.1208594813174; Sat, 19 Apr 2008 01:46:53 -0700 (PDT) Received: by 10.142.153.9 with HTTP; Sat, 19 Apr 2008 01:46:53 -0700 (PDT) Message-ID: Date: Sat, 19 Apr 2008 10:46:53 +0200 From: "Berke Durak" To: "Yaron Minsky" Subject: Re: [Caml-list] OCaml Summer Project decisions are in Cc: "Dario Teixeira" , "Caml List" In-Reply-To: <1208546581.16295.108.camel@nyc-qws-018.delacy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6843_11789127.1208594813173" References: <865618.45090.qm@web54601.mail.re2.yahoo.com> <1208546581.16295.108.camel@nyc-qws-018.delacy.com> X-Miltered: at concorde with ID 4809B17F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 ocaml:01 parallelism:01 allocations:01 bindings:01 damien:01 parallelism:01 allocations:01 bindings:01 damien:01 doligez:01 doligez:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_6843_11789127.1208594813173 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The concurrent GC is a great idea. A few interrogations. - How "stoppy" would a stop-the-world parallel GC be in practice? The more parallelism you have, the more work is done, the higher the frequency of a major collection. - Would major allocations be serialized? What about other serialization points? - I'm afraid true concurrency will introduce an awful lot of bugs in native bindings. Thread-unsafe libraries will have to be replaced (Str, etc.) Also what would be the CPU and memory costs? Don't concurrent GCs require extra colors? - In case of performance impacts, will the old single-threaded mode still be available? The argument that "you'll get the same old perfomance if you run it in single-threaded mode" is not valid IMHO. Many people will use a thread here or there and then you won't realistically be able to run in single-threaded mode. But then we can't pretend multi-core doesn't exist. A suggestion: making the parallel GC available only on 64-bit seems a reasonable restriction (if that's ever needed.) Also Damien Doligez (in addition to Xavier Leroy) certainly have nice things to say about all this. -- Berke Durak ------=_Part_6843_11789127.1208594813173 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The concurrent GC is a great idea.  A few interrogations.

- How "stoppy" would a stop-the-world parallel GC be in practice?  The more parallelism
you have, the more work is done, the higher the frequency of a major collection.

- Would major allocations be serialized?  What about other serialization points?

- I'm afraid true concurrency will introduce an awful lot of bugs in native bindings.  Thread-unsafe libraries will have to be replaced (Str, etc.)  Also what would be the CPU
and memory costs?  Don't concurrent GCs require extra colors?

- In case of performance impacts, will the old single-threaded mode still be available?

The argument that "you'll get the same old perfomance if you run it in single-threaded mode"
is not valid IMHO.  Many people will use a thread here or there and then you won't realistically be able to run in single-threaded mode.

But then we can't pretend multi-core doesn't exist.  A suggestion: making the parallel GC available only on 64-bit seems a reasonable restriction (if that's ever needed.)

Also Damien Doligez (in addition to Xavier Leroy) certainly have nice things to say about all this.
--
Berke Durak

------=_Part_6843_11789127.1208594813173--