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=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4A916BC6B for ; Tue, 18 Sep 2007 00:35:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANme7kbAXQInlGdsb2JhbACOEwIHBAYHCA X-IronPort-AV: E=Sophos;i="4.20,266,1186351200"; d="scan'208";a="2834222" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 18 Sep 2007 00:36:23 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8HMZmok006242 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 18 Sep 2007 00:35:50 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM2e7kZQW+UCh2dsb2JhbACOEwkKJw X-IronPort-AV: E=Sophos;i="4.20,266,1186351200"; d="scan'208";a="935263" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 Sep 2007 00:36:20 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IXPCQ-00019k-Es for caml-list@inria.fr; Tue, 18 Sep 2007 00:36:14 +0200 Received: from ivr94-8-88-162-26-239.fbx.proxad.net ([88.162.26.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Sep 2007 00:36:14 +0200 Received: from li by ivr94-8-88-162-26-239.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Sep 2007 00:36:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Zheng Li Subject: Re: [ANN] coThreads 0.10 Date: Tue, 18 Sep 2007 00:37:52 +0200 Message-ID: <873axc7wan.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> <1190064830.6058.255.camel@rosella.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ivr94-8-88-162-26-239.fbx.proxad.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:Id4k2DhA+BG7b3EiTEbqooJNSw4= Sender: news X-Miltered: at concorde with ID 46EF0144.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 speedup:01 speedup:01 model:01 users':01 0.10:98 threads:01 threads:01 sourceforge:01 abstract:01 pps:01 pps:01 immutable:01 immutable:01 Hi, skaller writes: > 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. Yes, you are right. The process engine is implemented with process. That's how it can speedup and that's why it's called ``process engine''. > 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) I'm sorry if the document misleadingly made you think it get speedup without using process and message passing. Threads and related tools is just the abstract interface on which all engines agree, they implement it with various facilities from VM threads, system threads to process or independent programs. > 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. For immutable value, it's not different from the traditional threads, at least from the library users' point of view: if a variable is already inside the scope of a threads (i.e. it's global and created before launching the thread), there is no necessity to message passing it; if not, you should anyway do it explicitly even with the traditional threads. Regards -- Zheng Li http://www.pps.jussieu.fr/~li