[pypy-commit] extradoc extradoc: stm blog post update

[Raemi]

Author: Remi Meier <remi.meier at gmail.com>
Branch: extradoc
Changeset: r5084:ff9a573f8094
Date: 2013-10-15 11:53 +0200
http://bitbucket.org/pypy/extradoc/changeset/ff9a573f8094/

Log:	stm blog post update

diff --git a/blog/draft/stm-oct2013.rst b/blog/draft/stm-oct2013.rst
--- a/blog/draft/stm-oct2013.rst
+++ b/blog/draft/stm-oct2013.rst
@@ -5,21 +5,27 @@
 
 the sprint in London was a lot of fun and very fruitful. In the last
 update on STM, Armin was working on improving and specializing the 
-automatic barrier placement.
-There is still a lot to do in that area, but that work was merged and
-lowered the overhead of STM over non-STM to around **XXX**. The same
-improvement has still to be done in the JIT.
+automatic barrier placement. There is still a lot to do in that area, 
+but that work is merged now. Specializing and improving barrier placement
+is still to be done for the JIT.
 
 But that is not all. Right after the sprint, we were able to squeeze
 the last obvious bugs in the STM-JIT combination. However, the performance
 was nowhere near to what we want. So until now, we fixed some of the most
 obvious issues. Many come from RPython erring on the side of caution
 and e.g. making a transaction inevitable even if that is not strictly
-necessary, thereby limiting parallelism.
-**XXX any interesting details? transaction breaks maybe? guard counters?**
-There are still many performance issues of various complexity left
+necessary, thereby limiting parallelism. Another problem came from 
+increasing counters everytime a guard fails, which caused transactions
+to conflict on these counter updates. Since these counters do not have
+to be completely accurate, we update them non-transactionally now with
+a chance of small errors.
+
+There are still many such performance issues of various complexity left
 to tackle. So stay tuned or contribute :)
 
+Performance
+-----------
+
 Now, since the JIT is all about performance, we want to at least 
 show you some numbers that are indicative of things to come.
 Our set of STM benchmarks is very small unfortunately 
@@ -61,6 +67,9 @@
 For comparison, disabling the JIT gives 492ms on PyPy-2.1 and 538ms on
 PyPy-STM.
 
+Try it!
+-------
+
 All this can be found in the `PyPy repository on the stmgc-c4
 branch <https://bitbucket.org/pypy/pypy/commits/branch/stmgc-c4>`_.
 Try it for yourself, but keep in mind that this is still experimental
@@ -68,7 +77,10 @@
 
 You can also download a prebuilt binary from here: **XXX**
 
-As a summary, what the numbers tell us is that PyPy-STM is, as expected,
+Summary
+-------
+
+What the numbers tell us is that PyPy-STM is, as expected,
 the only of the three interpreters where multithreading gives a large
 improvement in speed.  What they also tell us is that, obviously, the
 result is not good enough *yet:* it still takes longer on a 8-threaded
@@ -76,3 +88,8 @@
 by now, we are good at promizing speed and delivering it years later.
 It has been two years already since PyPy-STM started, so we're in the
 fast-progressing step right now :-)
+
+
+Cheers
+
+Armin & Remi