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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 118A7BBAF for ; Thu, 24 Sep 2009 16:22:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4CAKQdu0rRVdK1i2dsb2JhbACDAo5IiHg/AQEBCgsKBxEFqh2BMY9qAQMCBIQXBQ X-IronPort-AV: E=Sophos;i="4.44,445,1249250400"; d="scan'208";a="47203101" Received: from mail-yx0-f181.google.com ([209.85.210.181]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Sep 2009 16:22:30 +0200 Received: by yxe11 with SMTP id 11so2115025yxe.15 for ; Thu, 24 Sep 2009 07:22:27 -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=hVSweGAspl0tn3gjZLKHyvTtC9QLjQcDel/7BqGvVNY=; b=a579uzGGIwLjCQHVB/z9ZigZCFQRfD0kMVOxNB9s6VV6iJmZ2BIBZCmXh6SOW+MD0/ JJfm9jJ2g+orSEsUOX6PfxWvxWlXTQxTHm6VgqOdKyJtRH8j2c+Z+VSMKKk7XZNCwsqV hl6yhYCY+MNBBoIPPkzpSR5Ei/87WkL8DC/zg= 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=EXFcVDC3Vf3LDiozw6wWwssycNzAjNUjUjmWkn7Qg1Cf47ilKK7k1++Mm8ytmnU3NS lE9aK9DWRa/MXkqLs6L5KmOWK1DkVqOWJ9PVmiX8P4zGCws3f17A3K/V6ZJg7sF0wvml xN89HwqlDxjXrJfocQYyl3tZkuHDmvjuMzVN4= MIME-Version: 1.0 Received: by 10.100.129.13 with SMTP id b13mr4371000and.189.1253802147644; Thu, 24 Sep 2009 07:22:27 -0700 (PDT) In-Reply-To: <4ABB76E5.1060508@gulfsat.mg> References: <200909240247.17560.jon@ffconsultancy.com> <60112.70.26.45.183.1253786457.squirrel@pegasus.carleton.ca> <200909241252.24209.jon@ffconsultancy.com> <20090924123940.GA16175@usha.takhisis.invalid> <4ABB76E5.1060508@gulfsat.mg> Date: Thu, 24 Sep 2009 16:22:26 +0200 Message-ID: <4d1b2df20909240722m61507f15u3660449a3da0a232@mail.gmail.com> Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures From: Philippe Wang To: Rakotomandimby Mihamina Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 zacchiroli:01 ocaml:01 runtime:01 runtime:01 inria's:01 subjective:01 2009:98 2009:98 threads:01 threads:01 wrote:01 caml-list:01 slower:02 suited:02 On Thu, Sep 24, 2009 at 3:40 PM, Rakotomandimby Mihamina wrote: > 09/24/2009 03:39 PM, Stefano Zacchiroli: >> >> So, the real question is: is OC4MC going to be ported to mainline OCaml >> and support in the future or not? > > I dont write so much programs that would really require multiple cores. > But I think this is such a good "feature" that should be inclided in > the main distribution... Thing is that having a runtime library that supports parallel threads costs more than having a runtime library that doesn't. Programs that take advantage of multicore architectures are not easy to write, not easy to maintain, not easy to debug, ... So "it's a great feature, so it should get into mainstream" is not a good enough reason for INRIA's team. It's probably up to the community to find a great way of taking advantage of multicore architectures. One must be aware that - parallel threads vs not-parellel threads : if a program is well suited to parallel computing on multicore CPUs, then it means that not-parallel-capable runtime library puts the performance bottleneck at the CPU. Then, allowing parallel threads means *moving* this bottleneck (moving, not removing) : indeed, it's much likely that the bottleneck will then be at memory (RAM) bandwidth. See, if your memory is 1000 MHz, having 8 cores means 125MHz/core, which becomes ridiculous even if it were 2400MHz it would mean only 300MHz/core, imaging a 300MHz memory bandwidth for a 3GHz core ! So it's *very* important to keep that in mind. - for programming langages that are from the early beginning quite slower than INRIA OCaml, it's much easier to gain performance because they come from far, sometimes from very very far. Well, from a quite subjective personal point of view, of course it would be really great to give parallel threads capability to mainstream INRIA OCaml, because it would mean having found a (great) acceptable solution. -- Philippe Wang mail@philippewang.info