This has nothing to do with your questions, but are you sure that mvarInc is sufficiently strict?
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 <tkoster@gmail.com> 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 <shumovichy@gmail.com> 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 AllenCurrently working on http://haskellbook.com
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe