[Haskell-cafe] Is there any experience using Software Transactional Memory in substantial applications?

[Serguey Zefirov]

Thank you very much. This is just the answer I needed.

2010/8/8 Alberto G. Corona <agocorona at gmail.com>:
>
>
> ---------- Forwarded message ----------
> From: Alberto G. Corona <agocorona at gmail.com>
> Date: 2010/8/8
> Subject: Re: [Haskell-cafe] Is there any experience using Software
> Transactional Memory in substantial applications?
> To: Serguey Zefirov <sergueyz at gmail.com>
>
>
> This first papers is the first that describes the preliminary haskell
> implementation and the performance data says that STM scales well with the
> number of CPU cores  Blocking does not scale, as expected.
> http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/lock-free-flops06.pdf
> In this other study, also for microsoft:
>  Dissecting Transactional Executions in Haskell.
> The worst performance  in the study is from an extreme case example form my
> package TCache described here. In that example,  a set of treads update the
> same two objects all the time. Since STM is non  blocking, all threads tries
> to perform the task and rollback at the very end if things have been changed
> by other thread in the meantime. Just like databases. The bad thing is that
> the more CPU cores are executing the example, the more work being rolled
> back is done. That is more or less the history.
>  I heard (The Monad Reader -mplementing STM in pure Haskell)   about other
> tentative implementation that do not wait for the end of the atomic task to
> test the atomicity of the transaction, but instead, any update of a TVar
> inmediately invalidates (and kill) all  atomic transactions that uses that
> TVar. This could potentially improve the performance a lot.
> However I don´t know the strategy of the current haskell implementation nor
> the strasategy of the Microsoft runtime(s) either.
> Anyway, it is waranteed 100% that 1) the slowest in memory transaction is
> way faster than the transaction delegated to the fastest external database.
>  2) in memory transactions with blocking is a nightmare. For me  these are
> enough arguments for  STM usage in many ordinary (I mean Web) applications.
>
>
> 2010/8/8 Serguey Zefirov <sergueyz at gmail.com>
>>
>> Recently we discussed Haskell and especially types in Russian part of
>> LiveJournal and of course we talk about STM.
>>
>> My opponent gave me that link:
>>
>> http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with-software.html
>>
>> It says that performance with STM in Microsoft Research was more than
>> horrible.
>>
>> I failed to find convincing counter-evidence on the web. Not for
>> Haskell, even for Java/C#/C++.
>>
>> So I asking Haskell-cafe for clarification. Do anyone here have an
>> experience with STM in computing-intensive tasks? Did it help there?
>> What are the possible reasons for STM failure in MR?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>