Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r5515:4f27759c4bac Date: 2015-03-30 10:08 +0200 http://bitbucket.org/pypy/extradoc/changeset/4f27759c4bac/
Log: Prepare the blog post diff --git a/blog/draft/stm-mar2015.txt b/blog/draft/stm-mar2015.txt --- a/blog/draft/stm-mar2015.txt +++ b/blog/draft/stm-mar2015.txt @@ -1,10 +1,66 @@ -============= -Status of STM -============= +============================= +PyPy-STM 2.5.1 - Mawhrin-Skel +============================= -- stmgc-c7 reasonably good results, now porting to stmgc-c8 +We're pleased to announce PyPy-STM 2.5.1, Mawhrin-Skel. This is the +first full release of PyPy-STM. You can download this release here: -- stmgc-c7 results (with download link), explain the new - features + http://pypy.org/download.html -- stmgc-c8 in two words +Documentation: + + http://pypy.readthedocs.org/en/latest/stm.html + +This is a special version of PyPy that contains the "Software +Transactional Memory" (STM) core called stmgc-c7. It gives a +replacement for Python's classical Global Interpreter Lock (GIL). The +current version scales only up to around 4 cores; the next version of +the core, stmgc-c8, is in development and should address that +limitation. Both versions only supports 64-bit Linux for now +(contributions welcome). + +This is the first full release: it runs all regular PyPy tests. It +passes most of them... only, but that's still much better than the +previous versions. In other words, you should be able to drop in +PyPy-STM instead of the regular PyPy and your program should still +work. See `current status`_ for more information. + +.. _`current status`: http://pypy.readthedocs.org/en/latest/stm.html#current-status-stmgc-c7 + +It seems the performance is now more stable than it used to be. More +precisely, the best case is still "25%-40% single-core slow-down with +very good scaling up to 4 threads", but the average performance seems +not too far from that. There are still dark spots --- notably, the +JIT is still slower to warm up, though it was improved. Apart from +that, we should not get worse than 2x single-core slow-down in the +worst case. Please report such cases as bugs! + +This work was done by Remi Meier and Armin Rigo. Thanks to all donors +for `crowd-funding the STM work`_ so far! (As usual, it took longer +than we would have thought. I really want to thank the people that +kept making donations anyway. Your trust is great!) + +.. _`crowd-funding the STM work`: http://pypy.org/tmdonate2.html + + +TransactionQueue +---------------- + +PyPy-STM is more than "just" a Python without GIL. It is a Python in +which you can do minor tweaks to your existing, *non-multithreaded* +program, and get them to use multiple cores. The basic idea is to +identify medium- or large-sized likely-independent parts of the code, +like every iteration of some outermost loop over all items of a +dictionary; then ask PyPy-STM to try to run these parts in parallel. +This is done with a ``transaction.TransactionQueue`` instance. See +``help(TransactionQueue)`` or read more about it in `the STM user +guide`_. + +This is not a 100% mechanical change: very likely, you need to hunt +for and fix "STM conflicts" that prevent parallel execution (see +docs_). However, at all points your program runs correctly, and you +can stop the hunt when you get acceptable performance. You don't get +deadlocks or corrupted state. + +.. _`the STM user guide`: http://pypy.readthedocs.org/en/latest/stm.html#user-guide +.. _docs: http://pypy.readthedocs.org/en/latest/stm.html#transaction-transactionqueue _______________________________________________ pypy-commit mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-commit
