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.