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

Ketil Malde 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)
> performance.

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?)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants


More information about the Haskell-Cafe mailing list