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=2.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4A710BBAF for ; Thu, 24 Sep 2009 16:39:40 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0CACchu0rRVdLDkGdsb2JhbACDAoxWgXGIdz8BAQEBCQkMBxMDqk6BMY9rAQMCBIQXBQ X-IronPort-AV: E=Sophos;i="4.44,445,1249250400"; d="scan'208";a="34917052" Received: from mail-yx0-f195.google.com ([209.85.210.195]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Sep 2009 16:39:38 +0200 Received: by yxe33 with SMTP id 33so2373448yxe.0 for ; Thu, 24 Sep 2009 07:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dzGwiirqWSmzBIfMGeMxvL6xQci25XsQ+pTCUyt++2A=; b=UxHA0G9SpjbTEWckFEIY4Asm2NN06OI/Zb/PxXOPKopRAg5JeHLhzVjZxvgAj6/TGL r2Qz4Am3tHaNR9oCmY9YKzYOkb35IbyMcUMB9HDhhoIGRJZ3ZiQ/R4KpGq85pe5d2nz1 nLu3GxEykNS5kPzSKcHx6iuDK4SFDINl7fKqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qbV20GKpS1ALtspJD1KhprsxmNQKU/vHF2i3w4NZzyphMuw4MPFQXJWS5mL6AoeK5x UOfESjNtfuPs7ek0K6MLB8e+VP6RBEYNz5nW5WBCBRmbziPd/BWyXhIVB0uPIAHbSSp2 GGQbyyVedcUcStiShTuEzLn+n/F/xweyjY3zE= MIME-Version: 1.0 Received: by 10.101.46.15 with SMTP id y15mr4346844anj.4.1253803169877; Thu, 24 Sep 2009 07:39:29 -0700 (PDT) In-Reply-To: <613980.13877.qm@web111508.mail.gq1.yahoo.com> References: <613980.13877.qm@web111508.mail.gq1.yahoo.com> Date: Thu, 24 Sep 2009 16:38:06 +0200 Message-ID: <4d1b2df20909240738g1ba80204ra8cd138ef5c58956@mail.gmail.com> Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures From: Philippe Wang To: Dario Teixeira Cc: caml-list@inria.fr, Philippe Wang Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 cheers:01 compiler:01 compile-time:01 ocaml's:01 ocaml:01 merging:01 runtime:01 runtime:01 ocaml's:01 inria's:01 2009:98 threads:01 wrote:01 caml-list:01 On Thu, Sep 24, 2009 at 4:11 PM, Dario Teixeira wrote: > Hi, > > Cheers for the work you guys put into this project! And I'd like to join > the crowd that has questions, if I may: > > a) If I understand correctly, part of prerequisites for implementing the > new GC was cleaning up the excessive use of imperative constructs in > the compiler's tree. Will the new tree be also more amenable to the > implementation of new language constructs such as GADTs? Nope... We wanted not to touch the code generator (or any other part of the compiler). Eventually, we had to modify a very little bit the code generator so that it does not compact too much the generated code. That meant changing less than 10 lines of ml code. > b) Could you quantify the performance penalty (if any) of using the new GC > in a single-thread context? And should this penalty be significant, are > there provisions for a compile-time choice of which GC to use? Very few programs that are not written with multicore in mind would not be penalized. I mean our GC is much much dumber than INRIA OCaml's one. Our goal was to show it was possible to have good performance with multicores for OCaml. Maybe someday we'll find some time to optimize the GC, but it's likely not very soon. > c) Is there an understanding between you and the folks at INRIA concerning > the eventual merging of this code into the mainline tree? Almost same answer as the previous one. We have shown that it's possible to enjoy multicore for performance. The changes over the whole runtime library are not easy to merge into mainstream. It is very important to know this : the runtime library is written in C (and a little part is in ASM in order to have better performance... but mainly because of the "foreign function interface" so there is no way to ignore it). Its type system really sucks (comparing to OCaml's). When you change a very little part, it will tell you that you were wrong, but not with a hard-to-understand type error message : it will be some tricky dirty segmentation fault, which can sometimes that days or weeks, even months, to take down. I guess that if INRIA decides to implement parallel threads capability, they will have to make the runtime library ready (clean up some global variables, tidy the code like remove compatibility.h and such stuff) before thinking about the GC. This could take some time, because it's not good to break everything at once. Then, if they have finished this step, I would be confident that they could integrate an awesome GC. But that's only my personal opinion... Oh, why they wouldn't take OC4MC? ... If I were them, I wouldn't. We have probably broken some stuff such as Weak or Lazy, so there is no chance to bootstrap with OC4MC. Well, I mean that it's better to change INRIA's OCaml with all the lessons learnt than to try to fix OC4MC such that it's fully compatible with latest version of INRIA OCaml. -- Philippe Wang mail@philippewang.info