Simon Marlow <marlo...@gmail.com> writes: > On 17/08/2010 06:09, Gregory Collins wrote: > > We could provide a compare-and-swap on IORefs, indeed I've been > planning to try that so we could move the implementation of > atomicModifyIORef into user-space, so to speak.
For hash tables it would be nice to have a CAS indexing primitive on MutableArray#/MutableByteArray#/etc, also. >> Under load, pure data structures behind MVars don't perform well because >> of lock contention, and in my experience atomicModifyIORef is marginally >> better but still suffers from contention issues (probably related to >> thunk blackholing). > > This is the specific case that we addressed in the GHC runtime recently, and > you should find that 6.14 will perform a lot better than 6.12 with pure data > structures in mutable containers, especially with atomicModifyIORef. > > In the meantime you'll probably get better performance using STM. Whether you > should perform the update strictly inside the transaction or not is a matter > for experimentation, it probably depends on the data structure. In the specific benchmark in question STM was slightly slower than MVars (but that's pretty impressive!). G -- Gregory Collins <g...@gregorycollins.net> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe