Author: Armin Rigo <ar...@tunes.org> Branch: extradoc Changeset: r5152:b05e14b5a97b Date: 2014-02-09 10:54 +0100 http://bitbucket.org/pypy/extradoc/changeset/b05e14b5a97b/
Log: Draft blog post about the current status of stm diff --git a/blog/draft/stm-feb2014.txt b/blog/draft/stm-feb2014.txt new file mode 100644 --- /dev/null +++ b/blog/draft/stm-feb2014.txt @@ -0,0 +1,45 @@ +Hi all, + +A quick note about the Software Transactional Memory (STM) front. + +Since the <a +href="http://morepypy.blogspot.com/2013/10/update-on-stm.html";>previous +post</a>, we believe we progressed a lot by discovering an alternative +core model for software transactions. Why do I say "believe"? It's +because it means <i>again</i> that we have to rewrite from scratch the C +library handling STM. This is currently work in progress. Once this is +done, we should be able to adapt the existing pypy-stm to run on top of +it without much rewriting efforts; in fact it should simplify the +difficult issues we ran into for the JIT. + +You can read about the basic ideas of this new C library <a +href="https://bitbucket.org/pypy/stmgc/raw/c7/c7/README.txt";>here</a>. +It is still STM-only, not HTM, but because it doesn't constantly move +objects around in memory, it would be easier to adapt an HTM version. +There are even potential ideas about a hybrid TM, like using HTM but +only to speed up the commits. It is based on a <a +href="http://bpaste.net/show/177186/";>Linux-only</a> system call, <a +href="http://man7.org/linux/man-pages/man2/remap_file_pages.2.html";>remap_file_pages()</a> +(poll: who heard about it before? :-). As previously, the work is done +by Remi Meier and myself. + +Currently, the C library is incomplete, but early experiments show good +results in running <a +href="http://morepypy.blogspot.com/2013/07/software-transactional-memory-lisp.html";>duhton</a>, +the interpreter for a minimal language created for the purpose of +testing STM. Good results means we brough down the slow-downs from +60-80% to around 15%, from the non-STM-enabled to the STM-enabled +version on one thread (of course, the idea is that the STM version +scales when using more than one CPU core). + +This means that we are looking forward to a result that is much better +than originally predicted. The pypy-stm has chances to run at a +one-thread speed that is only "n%" slower than the regular pypy-jit, for +a value of "n" that is optimistically 15 --- but more likely some number +around 25 or 50. This is seriously better than the original estimate, +which was "between 2x and 5x". It would mean that using pypy-stm is +worthwhile even with two cores already. + +More updates later... + +Armin _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
