[pypy-commit] extradoc extradoc: merge

[fijal]

Author: fijal
Branch: extradoc
Changeset: r5732:f2de29b2d3a6
Date: 2016-10-06 13:58 +0200
http://bitbucket.org/pypy/extradoc/changeset/f2de29b2d3a6/

Log:	merge

diff --git a/blog/draft/jit-leaner-frontend.rst b/blog/draft/jit-leaner-frontend.rst
--- a/blog/draft/jit-leaner-frontend.rst
+++ b/blog/draft/jit-leaner-frontend.rst
@@ -5,18 +5,26 @@
 
 I'm pleased to inform that we've finished another round of
 improvements to the warmup performance of PyPy. Before I go
-into details, I'll recap achievements that we've done since we've started
+into details, I'll recap the achievements that we've done since we've started
 working on the warmup performance. I picked a random PyPy from November 2014
 (which is definitely before we started the warmup work) and compared it with
 a recent one, after 5.0. The exact revisions are respectively ``ffce4c795283``
 and ``cfbb442ae368``. First let's compare `pure warmup benchmarks`_ that
 can be found in our benchmarking suite. Out of those,
-``pypy-graph-alloc-removal`` could have been improved in the meantime by
-doing other work on PyPy, while the rest is purely focused on warmup.
+``pypy-graph-alloc-removal`` numbers should be taken with a grain of salt,
+since other work could have influenced the results.
+The rest of the benchmarks mentioned is bottlenecked purely by warmup times.
 
 You can see how much your program spends in warmup running
 ``PYPYLOG=jit-summary:- pypy your-program.py`` under "tracing" and "backend"
-fields.
+fields (in the first three lines). An example looks like that::
+
+    [e00c145a41] {jit-summary
+    Tracing:        71      0.053645 <- time spent tracing & optimizing
+    Backend:        71      0.028659 <- time spent compiling to assembler
+    TOTAL:                  0.252217 <- total run time of the program
+
+The results of the benchmarks
 
 +---------------------------+------------+------------+---------+----------------+----------------+
 | benchmark                 | time - old | time - new | speedup | JIT time - old | JIT time - new |
@@ -35,36 +43,41 @@
 As we can see, the overall warmup benchmarks got up to **90% faster** with
 JIT time dropping by up to **2.5x**. We have more optimizations in the pipeline,
 with an idea how to transfer some of the JIT gains into more of a total program
-runtime by jitting earlier and more eager.
+runtime by jitting earlier and more eagerly.
 
 Details of the last round of optimizations
 ------------------------------------------
 
 Now the nitty gritty details - what did we actually do? I covered a lot of
-warmup improvements in the past blog posts so I'm going to focus on
-the last change, jit-leaner-frontend branch. The last change is simple, instead of using
-pointers to store the "operations" object after tracing, we use a compact list of
-16-bit integers (with 16bit pointers in between). On 64bit machine the wins are
-tremendous - it's 4x more efficient to use 16bit pointers than full 64bit pointers.
-.. XXX: I assume you are talking about "memory efficiency": we should be clearer
-Additionally those pointers have a much better defined lifespan, so we don't need to
+warmup improvements in the `past`_ `blog`_ posts so I'm going to focus on
+the last change, the jit-leaner-frontend branch. This last change is simple, instead of using
+pointers to store the "operations" objects created during tracing, we use a compact list of
+16-bit integers (with 16bit pointers in between). On 64bit machine the memory wins are
+tremendous - the new representation is 4x more efficient to use 16bit pointers than full 64bit pointers.
+Additionally, the smaller representation has much better cache behavior and much less
+pointer chasing in memory. It also has a better defined lifespan, so we don't need to
 bother tracking them by the GC, which also saves quite a bit of time.
 
-Now the change sounds simple, but the details in the underlaying data mean that
+.. _`past`: http://morepypy.blogspot.com/2015/10/pypy-memory-and-warmup-improvements-2.html
+.. _`blog`: http://morepypy.blogspot.com/2015/09/pypy-warmup-improvements.html
+
+The change sounds simple, but the details in the underlaying data mean that
 everything in the JIT had to be changed which took quite a bit of effort :-)
 
-Going into the future in the JIT front, we have an exciting set of optimizations,
+Going into the future on the JIT front, we have an exciting set of optimizations,
 ranging from faster loops through faster warmup to using better code generation
 techniques and broadening the kind of program that PyPy speeds up. Stay tuned
 for the updates.
 
 We would like to thank our commercial partners for making all of this possible.
-The work has been performed by baroquesoftware.com and would not be possible
+The work has been performed by `baroquesoftware`_ and would not be possible
 without support from people using PyPy in production. If your company uses
 PyPy and want it to do more or does not use PyPy but has performance problems
-with the Python instalation, feel free to get in touch with me, trust me using
+with the Python installation, feel free to get in touch with me, trust me using
 PyPy ends up being a lot cheaper than rewriting everything in go :-)
 
+.. _`baroquesoftware`: http://baroquesoftware.com
+
 Best regards,
 Maciej Fijalkowski