From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3JA58Vx028196 for ; Tue, 19 Apr 2011 12:05:08 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8CAERdrU3VhjEVmWdsb2JhbACXMTGNRxQBAQEBAQgLCwcUJYhvvFuFcQSSAgc X-IronPort-AV: E=Sophos;i="4.64,238,1301868000"; d="scan'208";a="97515885" Received: from ihsmtp01cons.lis.interhost.com ([213.134.49.21]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Apr 2011 12:05:03 +0200 Received: from [192.168.1.64] ([178.166.9.223]) by ihsmtp01cons.lis.interhost.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Apr 2011 11:04:54 +0100 Message-ID: <4DAD5E4C.90700@inescporto.pt> Date: Tue, 19 Apr 2011 11:05:00 +0100 From: Hugo Ferreira User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: caml-list@inria.fr 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> <4D8CEAA4.2030403@inescporto.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 10:04:54.0737 (UTC) FILETIME=[3B2B1C10:01CBFE79] Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? On 04/19/2011 10:57 AM, Eray Ozkural wrote: > > > On Fri, Mar 25, 2011 at 9:19 PM, Hugo Ferreira > wrote: > > On 03/25/2011 06:24 PM, Martin Jambon wrote: > > On 03/25/2011 01:10 PM, Fabrice Le Fessant wrote: > > Of course, sharing structured mutable data between > threads will not be > possible, but actually, it is a good thing if you want > to write correct > programs ;-) > > > 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. > > > Cannot see how this works. Say I want to share a balanced binary tree. > Several processes/threads each take this tree and alter it by adding and > deleting elements. Each (new) tree is then further processed by other > processes/threads. > > How can get/set be used in this scenario? > > > I think it won't have good performance and it won't scale, and it will > fail for truly delicate shared memory architectures of the future with > thousands of cores.... > > And neither will it support on-chip message passing facilities of those > future processors. > > The shared memory message passing never worked too well, anyway, too > many redundant copies. Not fitting for high performance computing. > > No need at all except for embarrassingly parallel applications. I > suppose that's the target, right? > Yes. The problem is decomposable and can use sampling. The idea is to have threads that take a data-set decompose it and make the smaller parts available for further (parallel) processing. Regards, HF > Best, > > -- > Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara > http://groups.yahoo.com/group/ai-philosophy > http://myspace.com/arizanesil http://myspace.com/malfunct >