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 793D0BB81 for ; Wed, 8 Mar 2006 13:13:43 +0100 (CET) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28CDfJU022214 for ; Wed, 8 Mar 2006 13:13:42 +0100 Received: from [192.168.1.200] (ppp9-113.lns1.syd7.internode.on.net [59.167.9.113]) by ash25e.internode.on.net (8.13.5/8.13.5) with ESMTP id k28CDR6M025813; Wed, 8 Mar 2006 22:43:31 +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: <440EB4C2.2080102@asfandyar.cjb.net> References: <1474655.1141812700555.JavaMail.www@wwinf1632> <440EB4C2.2080102@asfandyar.cjb.net> Content-Type: text/plain Organization: Async P/L Date: Wed, 08 Mar 2006 23:23:05 +1100 Message-Id: <1141820585.20944.550.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440ECA75.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 haskell:01 async:01 2006:98 optimistic:98 quicker:98 consultants:98 wrote:01 sourceforge:01 sourceforge:01 caml-list:01 ghc:01 realtime:01 checking:02 explanation:03 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 Wed, 2006-03-08 at 10:41 +0000, Asfand Yar Qazi wrote: > Also, from what I remember, STM is "optimistic", while conventional lock-based > design is "pessimistic" - thereby allowing STM based code to spend less time > checking for locks or something, which apparently makes it quicker. > But, I'll lets the experts explain it :-) It isn't explanation that is needed but experience actually using it. The performance tradeoffs -- including developer time -- won't be evident until significant applications are developed using it. For example I wonder if the technique is worthwhile *without* the Haskell type system to enforce correctness? And given GHC is currently not generating very good code, will it matter anyhow? -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net