[Haskell-cafe] Proof of a multi-threaded application
ketil at malde.org
Tue Nov 18 05:04:13 EST 2008
Neil Davies <semanticphilosopher at googlemail.com> writes:
> 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)
I may not be asking the right question, but I am happy about the
answer, including yours :-)
I think STM is semantically the right tool for the (my) job, but for
it to be useful, the implementation must not be the limiting factor.
I.e running on n+1 CPUs should be measurably faster than running on n,
at least up to n=8, and preferably more.
With the assuming I can get enough parallelism and avoiding too many
rollbacks, of course.
> Others have already mentioned the granularity of locking - but that
> one of the performance design decisions that you need to quantify.
Yes. Fine grained - I'm thinking a large Array of TVars. (If you
only have a single TVar, it might as well be an MVar, no?)
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-Cafe