[pypy-commit] extradoc extradoc: some improvements to the evaluation section

cfbolz noreply at buildbot.pypy.org
Fri Aug 10 15:52:06 CEST 2012


Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4502:25325614a4fe
Date: 2012-08-10 15:50 +0200
http://bitbucket.org/pypy/extradoc/changeset/25325614a4fe/

Log:	some improvements to 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
@@ -609,7 +609,7 @@
 \end{description}
 
 From the mentioned benchmarks we collected different datasets to evaluate the
-Frequency, the overhead and overall behaviour of guards, the results are
+frequency, the overhead and overall behaviour of guards, the results are
 summarized in the remainder of this section. We want to point out three
 aspects of guards in particular
 \begin{itemize}
@@ -618,7 +618,7 @@
   \item Guard failures are local and rare.
 \end{itemize}
 
-All figures in this section do not take garbage collection into account. Pieces
+All figures in this section do not take garbage collection of machine code into account. 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
@@ -642,10 +642,10 @@
 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
+15.2\% to 20.2\% of the operations being compiled and later executed.
+The frequency of guard operations makes it important to store the associated
 information efficiently and also to make sure that guard checks are executed
-fast.
+quickly.
 
 \subsection{Overhead of Guards}
 \label{sub:guard_overhead}
@@ -667,7 +667,9 @@
 data} is the size of the compressed mapping from registers and stack to
 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}.
+in Section~\ref{sec:Resume Data}.\footnote{
+The size of the resume data is not measured at runtime, but reconstructed from
+log files.}
 
 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
@@ -688,16 +690,16 @@
 \end{figure}
 
 Why the efficient storing of the \texttt{resume data} is a central concern in the design
-of guards is illustrated by Figure~\ref{fig:backend_data}, this Figure shows
+of guards is illustrated by Figure~\ref{fig:backend_data}. This figure shows
 the size of the compressed \texttt{resume data}, the approximated size of
-storing the \texttt{resume data} without compression and the size of
-compressing the data to calculate the size of the resume data using the
+storing the \texttt{resume data} without compression and
+an approximation of the best possible compression of the resume data by
+compressing the data using the
 \texttt{xz} compression tool, which is a ``general-purpose data compression
-software with high compression ratio'' used to approximate the best possible
-compression for the \texttt{resume data}.\footnote{\url{http://tukaani.org/xz/}}.
+software with high compression ratio''.\footnote{\url{http://tukaani.org/xz/}}
 
 The results show that the current approach of compression and data sharing only
-requires 18.3\% to 31.1\% of the space compared to the naive approach. This
+requires 18.3\% to 31.1\% of the space compared to a naive approach. This
 shows that large parts of the resume data are redundant and can be stored more
 efficiently through using the techniques described above. On the other hand
 comparing the results to the xz compression which only requires between 17.1\%
@@ -711,8 +713,12 @@
 The last point in this discussion is the frequency of guard failures.
 Figure~\ref{fig:failing_guards} presents for each benchmark a list of the
 relative amounts of guards that ever fail and of guards that fail more than 200
-times. For guards that fail more than 200 times, as described before, a trace
-is recorded that starts from the guard, patching the guard so that later
+times.\footnote{
+    The threshold of 200 is rather high. It was picked experimentally to give
+    good results for long-running programs.
+}
+As described before, for guards that fail more than 200 times, a trace
+is recorded that starts from the guard. Afterwards the guard is patched so that later
 failures execute the new trace instead of taking the side-exit. Hence the
 numbers presented for guards that fail more than 200 times represent the 200
 failures up to the compilation of the bridge and all executions of the then
@@ -734,8 +740,6 @@
 not have unnecessary overhead.
 
 
-\todo{add a footnote about why guards have a threshold of 200}
-
 \section{Related Work}
 \label{sec:Related Work}
 


More information about the pypy-commit mailing list