From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id A05267ED26 for ; Thu, 7 Jun 2012 03:34:58 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscCAK4E0E+GoCGimWdsb2JhbABFsEyDfwEBAQEBCAsLBxQnghgBAQQBOEARCxgJFg8JAwIBAgFFEwgBAYgCBbh3ixgUgl+DFgOIPoxfhVONFoFHCQ X-IronPort-AV: E=Sophos;i="4.75,727,1330902000"; d="scan'208";a="146833685" Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Jun 2012 03:34:57 +0200 Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id F41D61260570 for ; Thu, 7 Jun 2012 10:34:52 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id D16DB1270063 for ; Thu, 7 Jun 2012 10:34:51 +0900 (JST) Message-ID: <4FD0053B.5020600@riken.jp> Date: Thu, 07 Jun 2012 10:34:51 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: caml-list@inria.fr References: <1339005692.4950.2@samsung> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.12418 Subject: Re: [Caml-list] Distributed computing libraries On 06/07/2012 05:52 AM, Thomas Braibant wrote: >> These are very different pieces of software, because they tackle problems at >> various abstraction levels. ocmc is the most level-level here, as it "only" >> tries to improve the runtime so that threads can be run in parallel on >> multiple cores. That's it, there is no additional abstraction on top of the >> standard threading API - no distribution, no computing. >> >> JoCaml uses the normal multi-threading in the runtime, but integrates it >> differently into the language. So, it adds abstraction, but you are still >> limited to a single core. >> >> So far I know, all the other libraries base on multi-processing to run >> programs on multiple cores. Plasma is the only one with true distribution >> capabiltiies beyond a single computer, but the price is that you must use >> the map/reduce scheme, whereas functory or parmap leave you more freedom. >> However, all multi-processing approaches share the property that the data >> flow is limited by process boundaries (unless you go really low-level and >> also take Netmulticore into consideration (part of Ocamlnet), which uses >> shared memory to overcome these limitations). >> >> I don't know what you are exactly looking for. Knowing the problem it would >> be easier to recommend something. > > Thanks a lot for this answer. > > As I said in another email, I do not have a problem to solve right > now. But, I was tickled by the Parmap announce, Don't hesitate, jump on it, that's really a nice technology. The "minimal disruption" concept is quite interesting. For example, if your List.iter is changed to a Parmap.pariter, the parallelization of this portion of the code is done. It's quite comfortable to develop and debug in single core mode (List.iter) and switch to the // version only once you're happy with the sequential one. Regards, F. > and I wondered how it > fared with the other related systems I knew about. (Yet, I reckon that > I should have made the question more precise, with a detailed lists of > criteria, akin to what Oliver suggested.) > > In my mind, asking on the list was the best way to make a good summary > of the current situation on this front. (But I am afraid I do not know > the best place to make public this kind of summaries.) >