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=1.9 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 74BB0BBAF for ; Sat, 26 Sep 2009 01:26:56 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMCAN/uvEpKfU4ZkGdsb2JhbACRS4h3PwEBAQEJCQwHEwOqKYE0j3QBAwIFhBkF X-IronPort-AV: E=Sophos;i="4.44,453,1249250400"; d="scan'208";a="47305004" Received: from ey-out-2122.google.com ([74.125.78.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2009 01:26:52 +0200 Received: by ey-out-2122.google.com with SMTP id 4so195902eyf.3 for ; Fri, 25 Sep 2009 16:26:51 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=G4HJKr/iW/2KrFXjur32PRw4yz63uDUUTpMyoxEqFUo=; b=ww9j/CcsQ022fP/qWsFhc+AfNxUgVtPDvaRQVA9f2ZM53TxdC2Yv0skURTmXCmYhTg 2Hl+nXP9lW4y7caobg81f33xzga48PGrjU+dJxQY1XjJgZJwnMmvl2SvpO5F++dQsDZ/ xFDeXzJXZXuzvmzYK1hZR+UUr2Jk5U+O1zDdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=GIxO3712b3xHreE7cHdI1KNVfTD3Q/Pw7SAD+atVqp20egHaQQ9TniAo7tkSFEhz5w wO4JAfdJbjHNi4M261rqFhJxOMtqBzINKPthhTEX0iGSE+6RfYpnJx5hbHpi6MIgxTOq l1J1h0/rLRaAShq09qhb3LsTTC248UVrwDilc= Received: by 10.211.130.13 with SMTP id h13mr224766ebn.81.1253921211562; Fri, 25 Sep 2009 16:26:51 -0700 (PDT) Received: from ?192.168.0.10? (ivr94-5-82-237-227-151.fbx.proxad.net [82.237.227.151]) by mx.google.com with ESMTPS id 10sm1176199eyd.29.2009.09.25.16.26.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Sep 2009 16:26:50 -0700 (PDT) Message-ID: <4ABD51BA.4010008@gmail.com> Date: Sat, 26 Sep 2009 01:26:50 +0200 From: Benjamin Canou User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures References: <200909241252.24209.jon@ffconsultancy.com> <20090924123940.GA16175@usha.takhisis.invalid> <200909241409.56894.jon@ffconsultancy.com> <4ABCDC24.2040806@inria.fr> In-Reply-To: <4ABCDC24.2040806@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 low-level:01 runtime:01 runtime:01 low-level:01 ocaml:01 parallelism:01 hacked:01 compiler:01 compiler:01 python's:01 hashtables:01 predictable:01 trivial:01 cheers:01 Hi everyone, And let's have a little prayer for Philippe who is now in bed, suffering from its head and hands because of his teammates letting him answer all the mail. Just (half) kidding. So, Xavier Leroy a wrote (and probably described the work quite well) : > what they did is an amazing hack [1] > indeed --, but you need to keep in mind the difference between a > proof-of-concept experiment and a product. By reading some messages in this thread I think we need to clarify again the context and goals of OC4MC. One of our main goals for OC4MC is to serve as a parallel and shared memory low-level concurrency implementation, on top of which higher level research concurrency libraries and language extensions can be built. And as most of us agree, multicores, and soon manycores, are hard to program, in particular because of the memory bandwidth. So there probably are experiments to be done to help this at the language level, now that we have this parallel runtime. Moreover, and to answer a question that appeared in this thread, we provide our simple GC, but we separated the GC algorithm from the runtime, so OC4MC is also a low-level playground to experiment with your own GCs and choose the one you want to use at linking. To sum up, let's see OC4MC as an experimentation platform that leverages some restrictions of OCaml, but of course neither as a drop-in replacement for the official distribution nor as the future of OCaml. We do not claim that the ideal solution to bring shared memory parallelism to OCaml is, as OC4MC does, only to replace the runtime (and that INRIA can just replace the official runtime by our hacked one). However, from a pragmatic (and optimistic) point of view, the modifications to the compiler have been kept very lightweight, yet sufficient to break binary compatibility. So if the excitement continues around OC4MC as in this thread, maybe these modifications could be integrated into the distribution since they really do not touch the core of the compiler and cannot cause a lot of maintenance overhead. I will add that we did not made this experiment to beat F# or python's hashtables, so I will not comment on that here. The point about performance is that it should be *predictable*. We now have rewritten and debugged most of the memory related behaviors present in the original runtime in a more generic (and OC4MC friendly) way to achieve this, and if it's not the case for some particular cases, we'll be glad to (try to) fix these bugs. On the maintenance side, as Philippe said, we already have some half working version with ocaml 3.11.x, but partly because of the changes made to the native runtime in this release and partly because of [1], porting the patch is not trivial. Cheers and have fun experimenting with OC4MC (so it will compensate the amount of debugging we spent on it ;-) ). Benjamin.