From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3LJrXB9029282 for ; Thu, 21 Apr 2011 21:53:33 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQCAJKKsE3RVdW2kWdsb2JhbAAvhCCgfQgUAQEBAQkLCwcUBCGpGoo4iA+Ib4Epg1B9BI4rigo6gx0 X-IronPort-AV: E=Sophos;i="4.64,252,1301868000"; d="scan'208";a="106442773" Received: from mail-yx0-f182.google.com ([209.85.213.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Apr 2011 21:53:28 +0200 Received: by yxl31 with SMTP id 31so25527yxl.27 for ; Thu, 21 Apr 2011 12:53:27 -0700 (PDT) Received: by 10.150.47.24 with SMTP id u24mr860679ybu.95.1303415607085; Thu, 21 Apr 2011 12:53:27 -0700 (PDT) MIME-Version: 1.0 Sender: hcarty@mulethief.com Received: by 10.150.182.2 with HTTP; Thu, 21 Apr 2011 12:53:07 -0700 (PDT) In-Reply-To: <20110421.210304.1267840107736400776.Christophe.Troestler+ocaml@umons.ac.be> References: <76544177.594058.1303341821437.JavaMail.root@zmbs4.inria.fr> <4DAFE141.7080003@inria.fr> <4DAFF442.8000806@lexifi.com> <20110421.210304.1267840107736400776.Christophe.Troestler+ocaml@umons.ac.be> From: "Hezekiah M. Carty" Date: Thu, 21 Apr 2011 15:53:07 -0400 X-Google-Sender-Auth: nbf2FMaYicmmVnFmldxYIL6VkrU Message-ID: To: Christophe TROESTLER Cc: alain.frisch@lexifi.com, caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3LJrXB9029282 Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? 2011/4/21 Christophe TROESTLER : > On Thu, 21 Apr 2011 11:09:22 +0200, Alain Frisch wrote: >> >> On 04/21/2011 09:48 AM, Fabrice Le Fessant wrote: >> > You think the programmers in the world that are only interested in >> > floating-point intensive computations, with fine-grain >> > concurrency, are a huge majority. I think they are not so >> > many. Can we do a better job of quantifying this ? >> >> [...] I guess we are in the nice niche of "embarassingly parallel" >> tasks.  Again, not so much because of the structure of the numerical >> problem itself, but because we need to run many independent >> instances of the problem. > > May you say why Functory is not good enough for this ? > http://www.lri.fr/~filliatr/functory/About.html > MPI [1] and ZeroMQ [2] are options as well. This may be getting a bit off topic - what does Functory offer over/in addition to these tools? [1] - http://forge.ocamlcore.org/projects/ocamlmpi/ [2] - https://github.com/pdhborges/ocaml-zmq Hez