From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 6C49DBC6B for ; Mon, 17 Sep 2007 23:32:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAK+N7kbAXQImn2dsb2JhbACOEwIHBAYHCBg X-IronPort-AV: E=Sophos;i="4.20,265,1186351200"; d="scan'208";a="933272" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Sep 2007 23:33:58 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8HLXNYB003041 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 17 Sep 2007 23:33:23 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAOQ7kbLENaMnmdsb2JhbACOEwIHBAYPGA X-IronPort-AV: E=Sophos;i="4.20,265,1186351200"; d="scan'208";a="16333745" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail4-smtp-sop.national.inria.fr with ESMTP; 17 Sep 2007 23:33:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFuL7kZ5LHvc/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.20,265,1186324200"; d="scan'208";a="193003706" Received: from ppp121-44-123-220.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.123.220]) by ipmail01.adl2.internode.on.net with ESMTP; 18 Sep 2007 07:03:52 +0930 Subject: Re: [Caml-list] Re: [ANN] coThreads 0.10 From: skaller To: Zheng Li Cc: caml-list@inria.fr In-Reply-To: <87odg16uzh.fsf@pps.jussieu.fr> References: <87lkb5fe3f.fsf@pps.jussieu.fr> <87sl5d8cgd.fsf@pps.jussieu.fr> <1190050760.6058.80.camel@rosella.wigram> <87odg16uzh.fsf@pps.jussieu.fr> Content-Type: text/plain Date: Tue, 18 Sep 2007 07:33:50 +1000 Message-Id: <1190064830.6058.255.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 46EEF2A3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 0200,:01 speedup:01 speedup:01 model:01 ocaml:01 compiler:01 ocaml:01 model:01 0.10:98 threads:01 threads:01 sourceforge:01 sourceforge:01 wrote:01 On Mon, 2007-09-17 at 19:51 +0200, Zheng Li wrote: > skaller writes: > > On Mon, 2007-09-17 at 18:48 +0200, Zheng Li wrote: > > > >> * The process engine can give you real speedup on multi-core and > >> multi-processor machines, the networker engine (todo) will give you both > >> speedup and scalability. > > I'm curious how this can be possible**.. is this only with the message > > passing model? > > ** Since Ocaml can't multi-process and neither the compiler > > nor library are modified .. > > Well, in order to have semantic consistency among different engines without > modifying standard OCaml itself, shard-memory style concurrency should only be > achieved through the STM module. It's documented in the pitfall pages: > > http://cothreads.sourceforge.net/doc/pitfall Yes but what I'm getting at is the claim of multi-processing, which Ocaml 3.10 at least cannot do. If you run Ocaml on a multi-core machine, even if you have 8 cores and 8 threads, one on each core, only one will ever run at once, so there is no performance gain. In fact, it will be slower than a single core. If you are *enforcing* message passing and using separate processes instead of threads, then 8 processes will run in parallel on 8 cores, and you'll get roughly 8 times speedup. So I'm not asking about how to ensure the code is consistent over the various models, but rather how you can get ANY genuine concurrency WITHOUT using message passing and processes (in which case the networking model should be easy to implement) Whether you explicitly send messages or use transactional memory or whatever to wrap the message passing isn't the question: I can see how that can work. However note, the message passing has to be used for immutable values too, if the threads are represented by processes in separate address spaces. -- John Skaller Felix, successor to C++: http://felix.sf.net