[Haskell-cafe] Proof of a multi-threaded application
semanticphilosopher at googlemail.com
Tue Nov 18 04:12:15 EST 2008
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
* 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.
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?
> If I haven't seen further, it is by standing in the footprints of
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe