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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id E564CBB81 for ; Wed, 8 Mar 2006 01:43:29 +0100 (CET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k280hRJI012553 for ; Wed, 8 Mar 2006 01:43:29 +0100 Received: from [192.168.1.200] (ppp9-113.lns1.syd7.internode.on.net [59.167.9.113]) by smtp3.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k280hOaa084817; Wed, 8 Mar 2006 11:13:25 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] STM support in OCaml From: skaller To: Asfand Yar Qazi Cc: caml-list@yquem.inria.fr In-Reply-To: <440DD982.8080800@asfandyar.cjb.net> References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> Content-Type: text/plain Organization: Async P/L Date: Wed, 08 Mar 2006 11:52:05 +1100 Message-Id: <1141779125.20944.405.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440E28AF.000 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 async:01 2006:98 consultants:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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 .. :) -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net