Author: mattip <matti.pi...@gmail.com>
Branch: extradoc
Changeset: r5565:8af39e15a6a9
Date: 2015-10-04 00:01 +0300
http://bitbucket.org/pypy/extradoc/changeset/8af39e15a6a9/
Log: some random changes, hopefully mostly improvements
diff --git a/blog/draft/warmup-improvements-2.rst
b/blog/draft/warmup-improvements-2.rst
--- a/blog/draft/warmup-improvements-2.rst
+++ b/blog/draft/warmup-improvements-2.rst
@@ -1,8 +1,8 @@
Hello everyone!
-This is the second part of the series of warmup improvements and
-memory consumption. This post covers recent work on sharing guard
+This is the second part of the series of improvement in warmup time and
+memory consumption in the PyPy JIT. This post covers recent work on sharing
guard
resume data that was recently merged to trunk. It will be a part
of the next official PyPy release. To understand what it does, let's
start with a loop for a simple example::
@@ -31,15 +31,15 @@
guard(i50 is false)
jump(p0, p1, p4, p6, p7, i47, i44, p15, p24, i46, i29,
descr=TargetToken(4364727712))
-Now each ``guard`` here needs a bit of data to know how to exit the compiled
-assembler into the interpreter, and potentially to compile a bridge in the
future.
-Since over 90% of guards never fail, this is incredibly wasteful - we have a
copy
+Now each ``guard`` needs a bit of data to know how to exit the compiled
+assembler back up to the interpreter, and potentially to compile a bridge in
the
+future. Since over 90% of guards never fail, this is incredibly wasteful - we
have a copy
of the resume data for each guard. When two guards are next to each other or
the
operations in between them are pure, we can safely redo the operations or to
simply
put, resume in the previous guard. That means every now and again we execute a
few
operations extra, but not storing extra info saves quite a bit of time and a
bit of memory.
-I've done some measurments on annotating & rtyping pypy which is pretty memory
hungry
-program that compiles a fair bit. I measured, respectively:
+I've done some measurments on annotating & rtyping translation of pypy, which
+is a pretty memory hungry program that compiles a fair bit. I measured,
respectively:
* total time the translation step took (annotating or rtyping)
@@ -61,8 +61,8 @@
| win | 4.8% | 5.5% | 19% | 26%
| 17% |
+---------+-----------------+--------------+-------------------+----------------+--------------+
-Obviously pypy translation is a bit extreme exampl - the vast majority of the
code out there
-does not have that much code involved that's being jitted. However, it's at
the very least
+Obviously pypy translation is an extreme example - the vast majority of the
code out there
+does not have that many lines of code to be jitted. However, it's at the very
least
a good win for us :-)
We will continue to improve the warmup performance and keep you posted!
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
