Re: [Haskell-cafe] When are MVars better than STM?

This has nothing to do with your questions, but are you sure that mvarInc is sufficiently strict? On 15:17, Sun, Jan 24, 2016 Christopher Allen wrote:

Well, there are cases where even with single-threading you want a memory barrier to prevent the CPU reordering instructions, but the shift to a single-threaded runtime should elide _some_ locks expressly designed to cope with multithreading.

On Sun, Jan 24, 2016 at 5:04 PM, Thomas Koster wrote:

...

Yuras,

On Sun, 2016-01-24 at 17:46 +1100, Thomas Koster wrote:

...

2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why?

On 25 January 2016 at 02:09, Yuras Shumovich wrote:

...

One possible explanation is closure locking which is not performed when there is only one capability. In my quick measurements it gives 40% speedup: https://ghc.haskell.org/trac/ghc/ticket/693#comment:9

This makes sense. After all, why bother with locks and barriers when the process is single-threaded anyway?

Thanks for your response.

-- Thomas Koster _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe