<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Alberto G. Corona</b> <span dir="ltr"><<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>></span><br>
Date: 2010/8/8<br>Subject: Re: [Haskell-cafe] Is there any experience using Software Transactional Memory in substantial applications?<br>To: Serguey Zefirov <<a href="mailto:sergueyz@gmail.com">sergueyz@gmail.com</a>><br>
<br><br><div>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.</div>
<div><br>
</div><a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/lock-free-flops06.pdf" target="_blank">http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/lock-free-flops06.pdf</a><div><br></div>
<div>In this other study, also for microsoft:</div>
<div><br></div><div><a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/lock-free-flops06.pdf" target="_blank"></a><span style="font-family:Georgia, serif;font-size:16px"> <a href="http://www.cs.rochester.edu/meetings/TRANSACT07/papers/perfumo.pdf" style="color:rgb(153, 153, 153);text-decoration:none" target="_blank">Dissecting Transactional Executions in Haskell</a>.</span></div>
<div><font face="Georgia, serif" size="4"><span style="font-size:16px"><br></span></font></div><div><font face="Georgia, serif" size="4"><span style="font-size:16px">The worst performance in the study is from an extreme case example form my package TCache described <a href="http://haskell-web.blogspot.com/2006/11/transactional-cache-for-haskell.html" target="_blank">here</a>. 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.</span></font></div>
<div><font face="Georgia, serif" size="4"><span style="font-size:16px"><br></span></font></div><div><font face="Georgia, serif" size="4"><span style="font-size:16px"> I heard (<a href="http://themonadreader.files.wordpress.com/2010/01/issue15.pdf" target="_blank">The Monad Reader -mplementing STM in pure Haskell</a>) 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. </span></font></div>
<div><font face="Georgia, serif" size="4"><span style="font-size:16px"><br></span></font></div><div><font face="Georgia, serif" size="4"><span style="font-size:16px">However I don´t know the strategy of the current haskell implementation nor the strasategy of the Microsoft runtime(s) either.</span></font></div>
<div><font face="Georgia, serif" size="4"><span style="font-size:16px"><br></span></font></div><div><font face="Georgia, serif" size="4"><span style="font-size:16px">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.<br>
</span></font><br></div><div><br></div><div><div class="gmail_quote">2010/8/8 Serguey Zefirov <span dir="ltr"><<a href="mailto:sergueyz@gmail.com" target="_blank">sergueyz@gmail.com</a>></span><div><div></div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently we discussed Haskell and especially types in Russian part of<br>
LiveJournal and of course we talk about STM.<br>
<br>
My opponent gave me that link:<br>
<a href="http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with-software.html" target="_blank">http://logicaloptimizer.blogspot.com/2010/06/so-microsofts-experiments-with-software.html</a><br>
<br>
It says that performance with STM in Microsoft Research was more than horrible.<br>
<br>
I failed to find convincing counter-evidence on the web. Not for<br>
Haskell, even for Java/C#/C++.<br>
<br>
So I asking Haskell-cafe for clarification. Do anyone here have an<br>
experience with STM in computing-intensive tasks? Did it help there?<br>
What are the possible reasons for STM failure in MR?<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></div></div><br></div>
</div><br>