From mboxrd@z Thu Jan 1 00:00:00 1970 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 p3JKR900015465 for ; Tue, 19 Apr 2011 22:27:09 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisCAEDvrU3U436rkWdsb2JhbACEUJJkjX0UAQEBAQkLCwcUAyKIb6tJkRoCgSeDTnoEiH+JBA X-IronPort-AV: E=Sophos;i="4.64,241,1301868000"; d="scan'208";a="93460604" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Apr 2011 22:27:03 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-067-144.pools.arcor-ip.net [84.59.67.144]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MHttJ-1Q8ijm3zDB-003hcG; Tue, 19 Apr 2011 22:26:52 +0200 Received: from [192.168.1.111] (546BE640.cm-12-4d.dynamic.ziggo.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 8A0995F701; Tue, 19 Apr 2011 22:26:51 +0200 (CEST) From: Gerd Stolpmann To: Eray Ozkural Cc: Hugo Ferreira , Martin Jambon , caml-list@inria.fr In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Apr 2011 22:26:49 +0200 Message-ID: <1303244809.8429.1272.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:XYi8WUXIGCa4EJBb4+O2XTIh3uNQaz/YMnN2hgW3dLs CSzo4+JhjPy6zURlEKbmhXguRAhL29C06tktHdSzR3rfujeI1s vJe7vWsHfnoSGcImVYHY8owOwAZTh8ntsLI7v1yoHUEpye9JuI W8aNeyhfZIeuBo6Jssi1cl08o/BNk/zkkNQvDTNXKb2uybu+FU S5IJ1STdhu3nWKffYIzjQ== Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? Am Dienstag, den 19.04.2011, 12:57 +0300 schrieb Eray Ozkural: > > > 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? I did experiment a bit in the meantime with Netmulticore [1], my implementation of multi-processing with shared memory. Netmulticore provides both alterable data structures and a quite efficient message passing interface. The experience so far: Message passing wins if you do it the right way. Avoid ping-pong games like get/set - shared memory is far better for this kind of operation. The better topology for message passing are pipelines where data flows only into one direction. I don't know how this translates to Hugo's machine learning problem. I could imagine a shared data structure is good here for providing the starting point for learning. If you run several learning steps in parallel, you want to avoid that these steps lock out each other, i.e. try to ensure that they affect distinct parts of the matrix. These updates would be sent (using message passing) to an update manager, which would apply the learning results to the matrix, and compute the next version, for which a number of new learning steps would be started. I'm just guessing here how it could be done. In my imagination a clever combination of both (alterable) shared memory and message passing is the way to go. Hugo, I'd like to do some more experiments into this direction. Is there a simple version of machine learning algorithm I could try to parallelize? Gerd [1] Netmulticore: now available in ocamlnet-3.3.0test1: http://blog.camlcity.org/blog/multicore2.html > > > 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 > -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------