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" <[EMAIL PROTECTED]> 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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
