Author: Remi Meier <remi.me...@inf.ethz.ch> Branch: extradoc Changeset: r5516:dcffa5ce26c7 Date: 2015-03-30 10:34 +0200 http://bitbucket.org/pypy/extradoc/changeset/dcffa5ce26c7/
Log: some rewording 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 @@ -16,29 +16,28 @@ 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 +limitation. Both versions only support 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 +This is the first full release: it passes all regular PyPy tests, +except for a few special cases. 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 +The performance is now more stable than it used to be. More +precisely, the best case is "25%-40% single-core slow-down with +very good scaling up to 4 threads", and 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 +JIT is still slower to warm up, though it was improved a lot. Apart from +that, we should not get more 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!) +kept making donations anyway. Your trust is greatly appreciated!) .. _`crowd-funding the STM work`: http://pypy.org/tmdonate2.html @@ -48,10 +47,10 @@ 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. +programs and get them to use multiple cores. The basic idea is to +identify medium- or large-sized, likely-independent parts of the code +and to ask PyPy-STM to run these parts in parallel. An example would be +every iteration of some outermost loop over all items of a dictionary. This is done with a ``transaction.TransactionQueue`` instance. See ``help(TransactionQueue)`` or read more about it in `the STM user guide`_. _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
