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

[John Lato]

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:
>
>> 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 at 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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160128/daf9b023/attachment.html>