#8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by jberryman): FWIW... Replying to [comment:1 tibbe]:
Atrocious results for the `IORef` solution! It seems like contended
`IORef`s don't work well at all. This is my experience. The behavior I've seen is interesting; check out the distribution of samples of a test of 100K concurrent `atomicModifyIORef`s, for 2 cores: [http://htmlpreview.github.io/?https://github.com/jberryman/chan- benchmarks/blob/master/reports/ghc-7.6/bench-multi.vars.html#b2] ...and 8 cores: [http://htmlpreview.github.io/?https://github.com/jberryman/chan- benchmarks/blob/master/reports/ghc-7.6_8-core/bench-multi.vars.html#b2] The `atomicModifyIORefCAS` from atomic-primops doesn't display that nasty spread; with the primitive CAS one thread always wins, but it seems like whatever GHC is doing is causing vicious retry loops, which sometimes stay in phase for awhile. And the fetch-and-add-based counter from `atomic-primops` handles contention far and away better than anything else available. From what I remember I couldn't even measure contention effects going from 2 to 8 contending threads (although I did do both tests on two different machines, so...). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8972#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler