[pypy-commit] extradoc extradoc: de-stress execution speed issues

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4766:bec24cddd1ec
Date: 2012-09-07 08:49 +0200
http://bitbucket.org/pypy/extradoc/changeset/bec24cddd1ec/

Log:	de-stress execution speed issues

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -125,8 +125,8 @@
 inserting operations called guards at points of possible divergence. These
 operations occur frequently in generated traces and therefore it is important to
 design and implement them carefully to find the right trade-off between
-execution speed, deoptimization,
-and memory overhead. In this paper, we perform an empirical analysis of runtime
+deoptimization, memory overhead, and (partly) execution speed.
+In this paper, we perform an empirical analysis of runtime
 properties of guards. This is used to guide the design of guards in the RPython
 tracing JIT.
 % \o/
@@ -166,15 +166,17 @@
 often.
 
 Besides being common, guards have various costs associated with them.
-Guards have a runtime cost, they take time to execute. Therefore it is
-important to make the on-trace execution of guards as efficient as possible. On
-the other hand, guards are possible deoptimization points. The recorded and
+Guards are possible deoptimization points. The recorded and
 compiled path has to be left if a guard fails, returning control to the
 interpreter. Therefore guards need enough associated information to enable
 rebuilding the interpreter state. The memory overhead of this information
-should be kept low. These constraints and trade-offs are what makes the design
+should be kept low. On the other hand,
+Guards have a runtime cost, they take time to execute. Therefore it is
+important to make the on-trace execution of guards as efficient as possible.
+These constraints and trade-offs are what makes the design
 and optimization of guards an important and non-trivial aspect of the construction
 of a tracing just-in-time compiler.
+ 
 
 %Section~\ref{sec:Evaluation} presents Figures about the absolute number of
 %operations for each benchmark, and the overhead produced by the information
@@ -185,7 +187,7 @@
 \begin{itemize}
   \item An analysis of guards in the context of RPython's tracing JIT,
   \item detailed measurements about the frequency and the
-  overhead associated with guards, and
+  memory overhead associated with guards, and
   \item a description about how guards are implemented in the high\-
   and low-level components of RPython's JIT and a description of the rationale behind the design.
 \end{itemize}