Author: David Schneider <david.schnei...@picle.org>
Branch: extradoc
Changeset: r4392:055a50512e96
Date: 2012-07-27 15:52 +0200
http://bitbucket.org/pypy/extradoc/changeset/055a50512e96/
Log: more on motivation and some typos
diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -126,9 +126,18 @@
operations in the traces produced by PyPy's tracing JIT and that guards are
operations that are associated with an overhead to maintain information about
state to be able to rebuild it, our goal is to present concrete numbers for the
-frecuency and the overhead produced by guards, explain how they are implemented
-in the diferent levels of PyPy's tracing JIT and explain the rationale behind
-the desing decisions based on the numbers.
+frequency and the overhead produced by guards, explain how they are implemented
+in the different levels of PyPy's tracing JIT and explain the rationale behind
+the design decisions based on the numbers.
+As can be seen on Figure~\ref{fig:ops_count} guards account for 14.42\% to
+22.32\% of the operations before and for 15.2\% to 20.12\% of after the
+optimization pass over the traced and compiled paths of the benchmarks.
+Figure~\ref{fig:benchmarks} shows the absolute number of operations for each
+benchmark, for every guard that stays alive after optimization there are
+several kinds of metadata created and stored at different levels of the JIT to
+be able to rebuild the interpreter or tracer state from a guard failure making
+the optimization \bivab{some good word} of guards an important aspect of the
+low-level design of a tracing just-in-time compiler.
\todo{extend}
\todo{contributions, description of PyPy's guard architecture, analysis on
benchmarks}
\begin{itemize}
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
http://mail.python.org/mailman/listinfo/pypy-commit
