[pypy-commit] extradoc extradoc: refactor another evaluation paragraph and mark pending tasks for the evaluation section

bivab noreply at buildbot.pypy.org
Mon Aug 6 13:35:39 CEST 2012


Author: David Schneider <david.schneider at picle.org>
Branch: extradoc
Changeset: r4431:b778249b970d
Date: 2012-08-06 13:35 +0200
http://bitbucket.org/pypy/extradoc/changeset/b778249b970d/

Log:	refactor another evaluation paragraph and mark pending tasks for the
	evaluation section

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -581,25 +581,30 @@
 \todo{add a footnote about why guards have a threshold of 100}
 
 The overhead that is incurred by the JIT to manage the \texttt{resume data},
-the \texttt{low-level resume data} and the generated machine code is shown in
-Figure~\ref{fig:backend_data}. It shows the total memory consumption of the
-code and of the data generated by the machine code backend for the different
-benchmarks mentioned above. The size of the machine code is composed of the
-size of the compiled operations, the trampolines generated for the guards and a
-set of support functions that are generated when the JIT starts and are shared
-by all compiled traces. The size of the \texttt{low-level resume data} is the
-size of the registers and stack to IR-level variable mappings and finally the
-size of the \texttt{resume data} is an approximation of the size of the
-compressed high-level resume data. While the \texttt{low-level resume data} has
-a size of about 15\% to 20\% of the generated instructions the \texttt{resume
-data} is even in the compressed form larger than the generated machine code.
+the \texttt{low-level resume data} as well as the generated machine code is
+shown in Figure~\ref{fig:backend_data}. It shows the total memory consumption
+of the code and of the data generated by the machine code backend and an
+approximation of the size of the \texttt{resume data} structures for the
+different benchmarks mentioned above. The size of the machine code is composed
+of the size of the compiled operations, the trampolines generated for the
+guards and a set of support functions that are generated when the JIT starts
+and are shared by all compiled traces. The size of the \texttt{low-level resume
+data} is the size of the compressed mapping from registers and stack to
+IR-level variable and finally the size of the \texttt{resume data} is an
+approximation of the size of the compressed high-level resume data\todo{explain
+why it is an approximation}.
 
-Tracing JITs compilers only compile a subset of the executed program so the
-amount of generated machine code will be smaller than for function based JITs.
-At the same time there is a several times larger overhead for keeping the
-resume information for the guards. The generated machine code accounts for
-20.21\% to 37.97\% of the size required for storing the different kinds of
-resume data.
+Compared to the size of the generated machine code the compressed
+\texttt{low-level resume data} is about 15\% to 20\% of that size, depending on
+the benchmark. On the other hand the generated machine code has only a size
+ranging from 20.21\% to 37.98\% of the size of the high and low-level
+\texttt{resume data} being compressed as described before.
+
+Tracing JIT compilers only compile the subset of the code executed in a program
+that is traced in a hot loop, for this reason the amount of generated machine
+code will be smaller than in other juts-in-time compilation approaches. Still
+the overhead associated to guards to resume execution from a side exit appears
+to be high.\bivab{put into relation to other JITs, compilers in general}
 
 \begin{figure*}
     \include{figures/backend_table}
@@ -613,12 +618,8 @@
 show the total amount of operations that are evaluated by the JIT and the
 total amount of code and data that is generated from the optimized traces.
 
-* Evaluation
-   * Measure guard memory consumption and machine code size
-   * Extrapolate memory consumption for guard other guard encodings
-      * compare to naive variant
-   * Measure how many guards survive optimization
-   * Measure the of guards and how many of these ever fail
+\todo{compare to naive variant of resume data}
+\todo{Measure the of guards and how many of these ever fail}
 
 \section{Related Work}
 \label{sec:Related Work}


More information about the pypy-commit mailing list