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 A0F997ED26 for ; Wed, 6 Jun 2012 22:52:30 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicCAL3Cz0/RVaG2imdsb2JhbABFtDEIIgEBAQoJDQcSBiOCGAEBAQMBEgIsARsdAQMBCwYFCwM4IgERAQUBHAY1h1oBAwYFmiMJA4wignCEdAoZJw1XiHEBBQyLIIV1A5Udjh0+hBuBOgk X-IronPort-AV: E=Sophos;i="4.75,725,1330902000"; d="scan'208";a="146820611" Received: from mail-gg0-f182.google.com ([209.85.161.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-MD5; 06 Jun 2012 22:52:30 +0200 Received: by ggnm2 with SMTP id m2so8124900ggn.27 for ; Wed, 06 Jun 2012 13:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gJru1WVlmFHZoenZDxeS90ib7SdsWrzsVTYLklyTQI4=; b=cR3JvxnWhiNJJMLsBKImvO0QyY8o9Lpw9iHrYrjNLKmHcqSzIibrZlDf9ZoS+An9Ay /VzgLXlgc9we3/Wi4g/CHuclof4j69VT36VhaEWc56fkN+r3MOtgOW/1iBzBpkzkd9ya ZgxVs4Pg3fNwqsaYyGk3Y2QcQ2B+4Xtek6COL2JaVJVyluWemJKbJqiUoVDOAIGs1JDm tbH6udA4lVl+uRYaObhBBHrSNime3V5Hn/IaS8p2jKVBSFBLhU1IuDcXuVoknunWRw3k K5clUQwj1hVcIpw42DbvLOiP5B04xZJYrd2yCgpmFqX4KkzM3ph+AiFUf1fl7l92wI4z dnbQ== Received: by 10.50.189.234 with SMTP id gl10mr8198991igc.59.1339015948456; Wed, 06 Jun 2012 13:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.135 with HTTP; Wed, 6 Jun 2012 13:52:08 -0700 (PDT) In-Reply-To: <1339005692.4950.2@samsung> References: <1339005692.4950.2@samsung> From: Thomas Braibant Date: Wed, 6 Jun 2012 16:52:08 -0400 Message-ID: To: Gerd Stolpmann Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Distributed computing libraries > 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, 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.)