[pypy-commit] extradoc extradoc: more tweaking

bivab noreply at buildbot.pypy.org
Thu Aug 16 10:07:51 CEST 2012


Author: David Schneider <david.schneider at picle.org>
Branch: extradoc
Changeset: r4589:e3857577930f
Date: 2012-08-15 16:01 +0200
http://bitbucket.org/pypy/extradoc/changeset/e3857577930f/

Log:	more tweaking

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -691,7 +691,7 @@
 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.
+the total amount of code and resume data that is generated.
 
 
 \subsection{Frequency of Guards}
@@ -705,10 +705,10 @@
 Figure~\ref{fig:benchmarks} extends Figure~\ref{fig:guard_percent} and 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. The Figure shows that the overall optimization rate for
+and optimized traces. The Figure also shows 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. This indicates that the optimizer can remove
+operations. This indicates that the optimizer can remove
 most of the guards, but after the optimization pass these still account for
 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
@@ -797,7 +797,7 @@
 \end{figure}
 
 From Figure~\ref{fig:failing_guards} we can see that only a very small amount
-of all the guards in the optimized traces ever fail. This amount varies between
+of all the guards in the compiled traces ever fail. This amount varies between
 2.4\% and 5.7\% of all guards. As can be expected, even fewer guards fail often
 enough that a bridge is compiled for them, only 1.2\% to 3.6\% of all guards
 fail often enough that a bridge is compiled. Also, of all failing guards a few fail extremely often
@@ -816,7 +816,7 @@
 compilers to represent possible divergent control flow paths.
 
 SPUR~\cite{bebenita_spur:_2010} is a tracing JIT compiler
-for a C\# virtual machine.
+for a CIL virtual machine.
 It handles guards by always generating code for every one of them
 that transfers control back to the unoptimized code.
 Since the transfer code needs to reconstruct the stack frames
@@ -834,20 +834,20 @@
 of snapshots for every guard to reduce memory pressure. Snapshots are only
 created for guards after updates to the global state, after control flow points
 from the original program and for guards that are likely to fail. As an outlook
-Pall mentions the plans to switch to compressed snapshots to further reduce
+Pall mentions plans to switch to compressed snapshots to further reduce
 redundancy. The approach of not creating snapshots at all for every guard is
 orthogonal to the resume data compression presented in this paper and could be
 reused within RPython to improve the memory usage further.
 
 Linking side exits to pieces of later compiled machine code was described first
-in the context of Dynamo~\cite{Bala:2000wv} under the name of Fragment Linking.
-Once a new hot trace is emitted into the fragment cache it is linked to side
+in the context of Dynamo~\cite{Bala:2000wv} under the name of fragment linking.
+Once a new hot trace is emitted into the fragment cache it is linked to the side
 exit that led to the compilation of the fragment. Fragment Linking avoids the
 performance penalty involved in leaving the compiled code. Fragment linking
 also allows to remove compensation code associated to the linked fragments that
 would have been required to restored the execution state on the side exit.
 
-Gal et. al~\cite{Gal:2006} describe how in the HotpathVM they experimented
+Gal et. al~\cite{Gal:2006} describe how in the HotpathVM, a JIT for a Java VM, they experimented
 with having one generic compensation code block, like the RPython JIT, that
 uses a register variable mapping to restore the interpreter state. Later this
 was replaced by generating compensation code for each guard which produced a
@@ -922,16 +922,16 @@
 flow divergence in recorded traces.
 Based on the observation that guards are a frequent operation in traces and
 that they do not fail often, we described how they have been implemented in the
-high and low level components of RPython's tracing JIT compiler.
+high- and low-level components of RPython's tracing JIT compiler.
 
 Additionally we have presented experimental data collected using the standard PyPy
-benchmark set to evaluate previous observations and assumptions. Our
+benchmark set to evaluate previous observations and assumptions about guards. Our
 experiments confirmed that guards are a very common
 operation in traces. At the same time guards are associated with a high
 overhead, because for all compiled guards information needs to be
 stored to restore the execution state in case of a bailout. The measurements
 showed that the compression techniques used in PyPy effectively reduce the
-overhead of guards, but it still produces a significant overhead. The results
+overhead of guards, but they still produce a significant overhead. The results
 also showed that guard failure is a local event: there are few
 guards that fail at all, and even fewer that fail very often.
 These numbers validate the design decision of reducing the overhead of
@@ -950,7 +950,7 @@
 failure.
 
 \section*{Acknowledgements}
-We would like to thank David Edelsohn and Stephan Zalewski for their helpful
+We would like to thank David Edelsohn, Samuele Pedroni and Stephan Zalewski for their helpful
 feedback and valuable comments while writing this paper.
 
 %\section*{Appendix}


More information about the pypy-commit mailing list