Author: David Schneider <david.schnei...@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}
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
http://mail.python.org/mailman/listinfo/pypy-commit
