Author: fijal
Branch: extradoc
Changeset: r5730:3241a7d679cc
Date: 2016-04-07 11:53 +0300
http://bitbucket.org/pypy/extradoc/changeset/3241a7d679cc/
Log: (fijal, cfbolz) work on blog post
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
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
