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 p2PFiaB3022288 for ; Fri, 25 Mar 2011 16:44:36 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsDAK23jE3VhjEVd2dsb2JhbACERKESFAEMCgoJFCWITalukR6BJ4NLdwSQSQY X-IronPort-AV: E=Sophos;i="4.63,243,1299452400"; d="scan'208";a="91137021" Received: from ihsmtp01cons.lis.interhost.com ([213.134.49.21]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Mar 2011 16:44:30 +0100 Received: from [192.168.1.64] ([178.166.9.223]) by ihsmtp01cons.lis.interhost.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Mar 2011 15:44:30 +0000 Message-ID: <4D8CB859.9040709@inescporto.pt> Date: Fri, 25 Mar 2011 15:44:25 +0000 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: Fabrice Le Fessant CC: Gerd Stolpmann , 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> In-Reply-To: <4D8C944A.9060601@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2011 15:44:30.0678 (UTC) FILETIME=[87D93760:01CBEB03] Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? Hi, Don't mean to drag this on but... On 03/25/2011 01:10 PM, Fabrice Le Fessant wrote: > On 03/25/2011 01:58 PM, Hugo Ferreira wrote: >>>> Assuming all shared data structures are immutable is it possible to: > > Well, Java has fully multi-threaded garbage collection, so there is no > point that it is possible to do it. > > The problem is that it has a cost, and the cost is a huge slowdown on > mono-threaded programs. Since most OCaml programs are mono-threaded, and > only few programs would really benefit from multi-threading, we are > trying to come up with a solution that would satisfy both worlds. > Mono-threaded programs would still run as fast (possibly using a > non-reentrant version of the runtime, to avoid the cost of TLS if it is > visible), and multi-threaded programs can be written easily. > Personally I think this is an "impossible" feat. Why not simply allow for the existence of two GC's and let the programmer select the one that is best for the application? > 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 ;-) > 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". R, Hugo F.