[Haskell-cafe] Proof of a multi-threaded application

[Neil Davies]

Ketil

You may not be asking the right question here. Your final system's  
performance is going to be influenced far more by your algorithm for  
updating than by STM (or any other concurrency primitive's) performance.

Others have already mentioned the granularity of locking - but that  
one of the performance design decisions that you need to quantify.

The relative merits of various approaches are going to come down to  
issues such as

   * given that you have a lock what is the cost of locking (in term  
of the lack of forward progress)
   * how often will you have to pay this cost (that will be  
application / data dependent)
   * given you use STM, what is the (differential) cost of the  
underlying housekeeping (depends what processing is with the  
'atomically')
   * what is the likelihood that you will have to undo stuff  
(represents the same cost as the lack of forward progress).

So the answer which is better, as it always is, will be - it depends

Welcome to the wonderful world of performance engineering.

The answer you seek is tractable - but will require more analysis.

Neil


On 18 Nov 2008, at 06:35, Ketil Malde wrote:

> "Tim Docker" <timd at macquarie.com.au> writes:
>
>>> My apologies for side-tracking, but does anybody have performance
>>> numbers for STM? I have an application waiting to be written using
>>> STM, boldly parallelizing where no man has parallelized before, but
>>> if it doesn't make it faster,
>
>> Faster than what?
>
> Faster than an equivalent non-concurrent program.  It'd also be nice
> if performance was comparable lock-based implementation.
>
>> Are you considering using STM just to make otherwise pure code run in
>> parallel on multiple cores?
>
> No, I have a complex structure that must be updated in non-predictable
> ways.  That's what STM is for, no?
>
> -k
> -- 
> If I haven't seen further, it is by standing in the footprints of  
> giants
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe