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