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 F2E23BB81 for ; Thu, 9 Mar 2006 00:01:45 +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 k28N1jbs020106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Mar 2006 00:01:45 +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 k28N1i5K025896 for ; Wed, 8 Mar 2006 23:01:44 GMT Message-ID: <440F6275.90301@asfandyar.cjb.net> Date: Wed, 08 Mar 2006 23:02:13 +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: <1474655.1141812700555.JavaMail.www@wwinf1632> <440EB4C2.2080102@asfandyar.cjb.net> <1141820585.20944.550.camel@budgie.wigram> In-Reply-To: <1141820585.20944.550.camel@budgie.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 440F6259.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 haskell:01 cjb:98 2006:98 optimistic:98 quicker:98 wrote:01 wrote:01 caml-list:01 imperative:01 ghc:01 checking:02 functional:02 functional:02 concurrent:02 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 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? > To tell the truth, I just want to be on the bleeding edge - hence my desire to get away from this horrid imperative programming I've been indoctrinated with, and to learn how to get the most out of tomorrows processors, which will all be multi-core. The answer to these problems is obvious - functional programming and concurrent programming. I intend to get experience in as many functional languages as possible so that whatever comes up in the future, I'll be able to get to grips with it. And (according to Tim Sweeny anyway) STM allows writing multithreaded apps "almost as easily as single threaded ones", so would be the solution to the headaches one normally associates with concurrent programming. But, we'll just have to wait and see.