Author: David Schneider <[email protected]>
Branch: extradoc
Changeset: r4495:e489325cfc9c
Date: 2012-08-10 13:23 +0200
http://bitbucket.org/pypy/extradoc/changeset/e489325cfc9c/
Log: more rewriting of 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
@@ -456,7 +456,7 @@
pseudo-assembler if the operation and the guard are compiled separated or if
they are merged.
-\bivab{Figure needs better formatting}
+\todo{Figure needs better formatting}
\begin{figure}[ht]
\noindent
\centering
@@ -609,7 +609,20 @@
From the mentioned benchmarks we collected different datasets to evaluate the
Frequency, the overhead and overall behaviour of guards, the results are
-summarized in the remainder of this section.
+summarized in the remainder of this section. We want to point out three
+aspects of guards in particular
+\begin{itemize}
+ \item Guards are very common operations in traces.
+ \item There is overhead associated with guards.
+ \item Guard failures are local and rare.
+\end{itemize}
+
+All figures in this section do not take into account garbage collection. Pieces
+of machine code can be globally invalidated or just become cold again. In both
+cases the generated machine code and the related data is garbage collected. The
+figures 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.
+
\subsection{Frequency of Guards}
\label{sub:guard_frequency}
@@ -618,15 +631,21 @@
\caption{Benchmark Results}
\label{fig:benchmarks}
\end{figure*}
+
Figure~\ref{fig:benchmarks} summarizes the total number of operations that were
recorded during tracing for each of the benchmarks and what percentage of these
operations are guards. The number of operations was counted on the unoptimized
-and optimized traces. Showing that the overall optimization rate is between
-65.80\% and 86.23\% of all operations and that the optimization rate for guards
-is similar to the general one, as could be assumed based on
-Figure~\ref{fig:guard_percent}. These numbers show that guards are a rather
-common operation in the traces, which is a reason the put effort into
-optimizing them.
+and optimized traces. The Figure shows that the overall optimization rate for
+operations which is between 69.4\% and 83.89\% of the traced operations and the
+optimization rate of guards, which is between 65.8\% and 86.2\% of the
+operations, are very similar, as could be assumed based on
+Figure~\ref{fig:guard_percent}. This indicates that the optimizer can remove
+most of the guards, but after the optimization pass guards still account for
+15.2\% to 20.2\% of the operations being compiled and later executed, the
+frequency of this operation makes it important to store the associated
+information efficiently and also to make sure that guard checks are executed
+fast.
+
\subsection{Overhead of Guards}
\label{sub:guard_overhead}
\begin{figure}
@@ -640,33 +659,26 @@
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
+different benchmarks mentioned above. The machine code taken into account is
+composed of the compiled operations, the trampolines generated for the guards
+and a set of support functions that are generated when the JIT starts and which
+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}.
+IR-level variables and finally the size of the \texttt{resume data} is an
+approximation of the size of the compressed high-level resume data as described
+in Section~\ref{sec:Resume Data}\todo{explain why it is an approximation}.
-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.
+For the different benchmarks the \texttt{low-level resume data} has a size of
+about 15\% to 20\% of the amount of memory compared to the size of the
+generated machine code. On the other hand the generated machine code has only a
+size ranging from 20.5\% to 37.98\% of the size of the high and low-level
+\texttt{resume data} combined and 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}
-
-
-Both figures do not take into account garbage collection. Pieces of machine
-code can be globally invalidated or just become cold again. In both cases the
-generated machine code and the related data is garbage collected. The figures
-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.
+code will be smaller than in other juts-in-time compilation approaches. This
+creates a larger discrepancy between the size of the \texttt{resume data} when
+compared to the illustrates why it is important to compress this information.
\todo{compare to naive variant of resume data}
_______________________________________________
pypy-commit mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-commit
