From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3KJOaGp003867 for ; Wed, 20 Apr 2011 21:24:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAKkyr01KfVK2kGdsb2JhbACEUKBnCBQBAQEBCQkNBxQEIYhvon+KOIJhAQWONQEEgSmDTnqYKDo X-IronPort-AV: E=Sophos;i="4.64,247,1301868000"; d="scan'208";a="93519500" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Apr 2011 21:24:06 +0200 Received: by wyf23 with SMTP id 23so1621604wyf.27 for ; Wed, 20 Apr 2011 12:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Z9IOOilpTd6t9YJMcVnW/+aRrNx48kZm2dmIMBePtfs=; b=AayghQL5INask1UTY4iMQDzcGFsf/MxJVjawCL7WBRa/HaBWt9qrXX4POm+0bLJfAo FoLdnyntnieN1lngmN0uWDByOsxNo+Rs9zN2zTHCwR/C8A4N8CW+scwkXczsRpBIeo/z HbJZhUml5VyVyZNRrg+L7/uFE4/pwkxW2ohSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; b=dDOCxoPpsIBILr8le+bFtKo20BqKXHEfegkU98VW5s7cJm4LnZ25jOcgNXMNaamj3s OVzYAre8MAoI/HgwDJ+g6qLurL4+hph4k9aWQ3sEVTVQ9m9NPEADpvLtQnEA+jRInz56 hy44M9OI5zqF5YqDvwcsXi42PChZJd6GMTUl0= Received: by 10.227.179.140 with SMTP id bq12mr268230wbb.152.1303327445410; Wed, 20 Apr 2011 12:24:05 -0700 (PDT) Received: from WinEight ([80.229.123.248]) by mx.google.com with ESMTPS id l24sm758166wbc.13.2011.04.20.12.24.02 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 12:24:03 -0700 (PDT) From: Jon Harrop To: "'Martin Jambon'" Cc: "Caml List" References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <4D8C73C8.6020801@inescporto.pt> <1301055903.8429.314.camel@thinkpad> <341494683.237537.1301057887481.JavaMail.root@zmbs4.inria.fr> <4D8C944A.9060601@inria.fr> <4D8CB859.9040709@inescporto.pt> <4D8CDDCC.4010000@ens-lyon.org> In-Reply-To: <4D8CDDCC.4010000@ens-lyon.org> Date: Wed, 20 Apr 2011 20:23:48 +0100 Organization: Flying Frog Consultancy Message-ID: <029701cbff90$7a874510$6f95cf30$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhMASujb2QG2h3N2h7/lJjoQ23OAIYQRkZAge6bucBi7oV8gIGVE8/AmcCvngCudDnUAFa0vZTlMtSIIA= Content-Language: en-gb Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3KJOaGp003867 X-Validation-by: jon@ffconsultancy.com Subject: RE: [Caml-list] Efficient OCaml multicore -- roadmap? Martin wrote: > On 03/25/11 08:44, Hugo Ferreira replied: > > I'll stick to my guns here. It simply makes solving certain problem > > unfeasible. Point in case: I work on machine learning algorithms. I > > use large data-structures that must be processed (altered) in order to > > learn. Because these data-structures are large it become impractical > > to copy this to a process every time I start off a new "thread". > > The solution would be to use get/set via a message-passing interface. The main objective when parallelizing a program is to remove focal points because they are sources of contention. Funnelling all IO through a single getter/setter would add a focal point and, most likely, destroy scalability. > From my purely speculative perspective, it seems unavoidable that message- > passing happens at some level in order to keep a shared data structure in sync > between a large number of processors. In other words, any access to a shared > data structure requires some physical copy no matter what the programming > language makes it look like. Yes. The hardware maintains the illusion of shared memory so the programmer only need optimize on the basis of an accurate cost model. There is no need to burden the programmer with message passing and manual memory management. Cheers, Jon.