Thank you very much. This is just the answer I needed.
2010/8/8 Alberto G. Corona <[email protected]>: > > > ---------- Forwarded message ---------- > From: Alberto G. Corona <[email protected]> > Date: 2010/8/8 > Subject: Re: [Haskell-cafe] Is there any experience using Software > Transactional Memory in substantial applications? > To: Serguey Zefirov <[email protected]> > > > 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 <[email protected]> >> >> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
