Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r5163:61f1eb9baa3a Date: 2014-03-15 12:08 +0100 http://bitbucket.org/pypy/extradoc/changeset/61f1eb9baa3a/
Log: Add a blog draft diff --git a/blog/draft/stm-mar2014.txt b/blog/draft/stm-mar2014.txt new file mode 100644 --- /dev/null +++ b/blog/draft/stm-mar2014.txt @@ -0,0 +1,29 @@ +Hi all, + +Here is <a +href="http://cobra.cs.uni-duesseldorf.de/~buildmaster/misc/pypy-c-r69967+-stm-1d0b870195e7.tbz2";>one +of the first full PyPy's</a> compiled with the new <a +href="http://morepypy.blogspot.ch/2014/02/rewrites-of-stm-core-model-again.html";>StmGC-c7 +library</a>. It has no JIT so far, but it runs some small +single-threaded benchmarks by taking around 40% more time than a +corresponding non-STM, no-JIT version of PyPy. It scales --- up to two +threads only, which is the hard-coded maximum so far in the c7 code. +But the scaling looks perfect in these small benchmarks without +conflict: starting two threads each running a copy of the benchmark +takes almost exactly the same amount of total time, simply using two +cores. + +Feel free to try it! It is not actually useful so far, because it is +limited to two cores and CPython is something like 2.5x faster. One of +the important next steps is to re-enable the JIT. Based on our <a +href="https://bitbucket.org/pypy/pypy/raw/stmgc-c7/TODO";>current +understanding</a> the "40%" figure, we can probably reduce it with +enough efforts; but also, the JIT should be able to easily produce +machine code that suffers a bit less than the interpreter from these +effects. This seems to mean that we're looking at 20%-ish slow-downs +for the future PyPy-STM-JIT. + +Interesting times :-) + + +Armin (as well as Remi for the work) _______________________________________________ pypy-commit mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-commit
