[pypy-commit] extradoc extradoc: Prepare the blog post

[arigo]

Author: Armin Rigo <arigo at tunes.org>
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