From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 1A411BB81 for ; Wed, 8 Mar 2006 11:36:49 +0100 (CET) Received: from outmail.freedom2surf.net (outmail1.freedom2surf.net [194.106.33.237]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k28AamXS030256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Mar 2006 11:36:48 +0100 Received: from [10.0.0.1] (i-195-137-83-147.freedom2surf.net [195.137.83.147]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k28Aal5K011422 for ; Wed, 8 Mar 2006 10:36:48 GMT Message-ID: <440EB436.7010704@asfandyar.cjb.net> Date: Wed, 08 Mar 2006 10:38:46 +0000 From: Asfand Yar Qazi User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060217) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] STM support in OCaml References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> In-Reply-To: <1141779125.20944.405.camel@budgie.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 440EB3C0.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 bounded:01 cached:01 cited:01 incrementing:01 threads:01 api:01 model:01 posix:01 mutexes:01 subset:01 ocaml:01 cjb:98 2006:98 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=DNS_FROM_RFC_WHOIS autolearn=disabled version=3.0.3 skaller wrote: > On Tue, 2006-03-07 at 19:05 +0000, Asfand Yar Qazi wrote: > > >>You make several claims: >> >>STM is not lock free. >>STM is not useful on a small number of processors >> >>As for claim 1. "Lock-free" doesn't mean what you think it does. > > > I know what STM does, thank you: I intend to implement it > myself in my own programming language. Maybe you should > read more carefully. > > I said "protected by a mutex under the hood." which means > sure, the programmer is not writing locks, but they're used > in the implementation and the associated costs are still paid. > > I really hate it when people try to throw papers against > simple logic. I said what the tradeoffs where: > > "It simply limits the locking period > to a bounded time, at the expense of the whole transaction > taking unbounded time." > > and then elaborated the conditions under which this > made sense. > > Long locking period on a Uniprocessor not only do not > cause problems they can actually IMPROVE performance by preventing > expensive context switches. > > A paper is cached here on my website, probably one of the > ones you cited. > > http://felix.sourceforge.net/papers/ea8-composablememory_stm.pdf > > It's quite interesting and I've bought a dual core CPU specifically > to test it out. The only numbers I can give you are based on a simple > lock test on a dual core G5 incrementing an integer: 15x SLOWER > on a dual processor than a uniprocessor with two threads. > > No doubt because of the weak support provided by Linux. > Windows may do better, haven't tried yet, but I doubt anything > older than Vista has suitable API support. > > In the end, fast concurrency is going to depend on both CPU and > board design and OS support. The point of the above paper is > not performance: the point is as I said, Sebastian said, > AND the paper emphasises: it provides a model which > supports composition. > > I point out that in fact, under the right conditions -- lots > of processors and lots of variables -- it will probably provide better > performance too. However this is hard to test -- not many > of us have access to >2 cores on the same board. There certainly > no way POSIX can deliver good performance: mutexes have to be > synchronisation points and that requires ALL the CPUs to > flush their caches -- it doesn't scale. Message passing does, > since sender and receiver only need to sync the message. > Explicit coupling, and both the subset of processor and > memory are limited. > > Oh, and Ocaml supports message passing between processes .. :) > Bad form on my part old chap - didn't realise your level of expertise.