From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3DN4pXJ008513 for ; Thu, 14 Apr 2011 01:04:51 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsDAMkqpk3ZSMDqkWdsb2JhbACYcI00FAEBAQEJCwsHFAMiiG+5e4VuBJFZ X-IronPort-AV: E=Sophos;i="4.64,207,1301868000"; d="scan'208";a="105591440" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Apr 2011 01:04:45 +0200 Received: from smtp04.web.de ( [172.20.0.225]) by fmmailgate03.web.de (Postfix) with ESMTP id B7C4918B52F11 for ; Thu, 14 Apr 2011 01:04:45 +0200 (CEST) Received: from [78.43.204.177] (helo=frosties.localnet) by smtp04.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #2) id 1QA977-0005uu-00 for caml-list@inria.fr; Thu, 14 Apr 2011 01:04:45 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.72) (envelope-from ) id 1QA977-0003M6-9k for caml-list@inria.fr; Thu, 14 Apr 2011 01:04:45 +0200 From: Goswin von Brederlow To: caml-list@inria.fr References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <4DA51A28.1060709@inf.ed.ac.uk> <1302699676.8429.1216.camel@thinkpad> Date: Thu, 14 Apr 2011 01:04:45 +0200 In-Reply-To: <1302699676.8429.1216.camel@thinkpad> (Gerd Stolpmann's message of "Wed, 13 Apr 2011 15:01:16 +0200") Message-ID: <87fwplkb1u.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1+RROUiQme+xe/vuhVYzT6jC+imIuoFci9Uhwdn RsFm87qGavAGLfw1hxidWN335T6sIKXcJQlAP2b6V8ylnp5YWe yqwgIJ/3A= Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? Gerd Stolpmann writes: > You may be interested then in this pre-announcement I posted yesterday: > > http://blog.camlcity.org/blog/multicore1.html > > I was able to make good progress on my Netmulticore library, which - > without changing anything in the compiler or runtime - allows it to > write multicore-enabled shared memory programs following the > "multi-runtime" design (which is emulated by forking subprocesses). > > More on this later. I'm working on a release. > > Gerd I believe this is a good way to go. In many cases you have only a small set of shared data (might be huge in bytes but small in structure) and then you have a ton of purely local (temporary) data each thread creates while processing. Idealy I would prefer the compiler detecting which data is local and which shared but I don't think that is easy if even feasable to get right. So let the user do some work. A slightly different design could be to still have the local and shared heap but automaticaly migrate values to the shared heap if and when they are shared the first time. This would mean dropping the automatic locks on shared values and have the user take care of locking properly as needed. MfG Goswin