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 p2P0NiDa012860 for ; Fri, 25 Mar 2011 01:23:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikEAMffi01QW+UMgWdsb2JhbAClTBQBARYmJYhNvDSFaQSMbw X-IronPort-AV: E=Sophos;i="4.63,240,1299452400"; d="scan'208";a="91077923" Received: from lo.gmane.org ([80.91.229.12]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Mar 2011 01:23:38 +0100 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2uoS-0000la-W1 for caml-list@inria.fr; Fri, 25 Mar 2011 01:23:36 +0100 Received: from avelizy-155-1-55-209.w86-217.abo.wanadoo.fr ([86.217.30.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2011 01:23:36 +0100 Received: from sylvain by avelizy-155-1-55-209.w86-217.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2011 01:23:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Date: Fri, 25 Mar 2011 00:23:21 +0000 (UTC) Message-ID: References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: avelizy-155-1-55-209.w86-217.abo.wanadoo.fr User-Agent: slrn/pre1.0.0-18 (Linux) Subject: [Caml-list] Re: Efficient OCaml multicore -- roadmap? On 24-03-2011, Fabrice Le Fessant wrote: > This is a multi-part message in MIME format. > --------------010005060004040101060205 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > Hi, > > Actually, I had a discussion two weeks ago with Xavier and Damien > about this issue. There is some kind of agreement that the ocaml way of > supporting multicore would be to have several runtimes running in the > same process, in different threads. That way, the GC would still be > mono-threaded, so almost no speed loss for mono-threaded programs (i.e. > currently all OCaml programs ;-) ). There would be some kind of "fork" > function, that would create a new thread running a function in a new > heap, probably generated by a copy-on-need algorithm. That is a very good idea. I think this should be the less expensive solution. I hope to see this implemented. > The different threads would not share heap memory, but would be > allowed to share structures outside of their heaps, probably for > simple types like strings and int/float arrays (or using the Ancient > library). > I think that you should basically left this "sharing" topic open. Create communication channel and allow to send the address of a C allocated structure (not managed by by the GC, of course). > Now, there are still two problems: > (1) We don't know yet how to implement that in a portable way. TLS > (Thread-local storage) is only available on a few architectures. And not > using TLS implies non-backward compatible changes to the FFI > (Foreign-Functions Interface), i.e. all stub libraries would have to be > rewritten. Well, I have thought about this issue a lot during the last months. Currently my best idea is to use a keyword "reentrant" for foreign function (just as "noalloc"). If an external function is marked "reentrant", you pass an additional parameters to the function, which is the context for doing allocation and other things. If an external function is not markd "reentrant", you acquire a general lock and do as usual (or use TLS or whatever). This "reentrant" keyword could be applied to a limited set of functions of the OCaml runtime, to begin the benchmarks. Once it seems ok, you can generalize the solution. > (2) As Gerd pointed it, there are not so many programs that would > benefit from that. Though I agree, I think a roadmap is a good point to show that INRIA OCaml team is working on this issue. Today, even a half-working solution for // will be better than nothing inside the INRIA OCaml core distribution. > So it is not currently on the top of our priority list, although I am > planning to give it a try in the next months, at least for the TLS > version. > I wish you good luck. Cheers, Sylvain Le Gall -- My company: http://www.ocamlcore.com Linkedin: http://fr.linkedin.com/in/sylvainlegall Start an OCaml project here: http://forge.ocamlcore.org OCaml blogs: http://planet.ocamlcore.org