[Haskell-cafe] When are MVars better than STM?
jwlato at gmail.com
Thu Jan 28 05:26:17 UTC 2016
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 <cma at bitemyapp.com> 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 <tkoster at gmail.com> wrote:
>> 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 at gmail.com>
>> > 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 at haskell.org
> Chris Allen
> Currently working on http://haskellbook.com
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe