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

Reply via email to