[pypy-commit] extradoc extradoc: Address some of the open tasks in the introduction and abstract sections

[bivab]

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

Log:	Address some of the open tasks in the introduction and abstract
	sections

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -108,9 +108,11 @@
 \keywords{tracing JIT, guards, deoptimization}
 
 \begin{abstract}
-Guards operations occur frequently in traces generated by tracing just-in-time
-(JIT) compilers. Therefore it is important to design and implement them
-carefully to find the right trade-off between execution speed, deoptimization,
+Tracing just-in-time (JIT) compilers record linear control flow paths,
+inserting operations called guards at points of possible divergence. These
+operations occur frequently 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 describe the design decisions about
 guards taken in the implementation of the RPython tracing JIT. Furthermore we
 measure various properties of guards.
@@ -125,32 +127,34 @@
 \cfbolz{the first two two paragraphs talk about deoptimization, then it
 switches to guards. I would say we should only talk about guards in the
 beginning}
-\bivab{Introduce in a sentence what guards are}
-In this paper we describe and analyze how guards, as a concept of tracing just-in-time compilers, work. Explicating what concepts are used in the
-intermediate and low-level representation of the JIT instructions and how these
-are implemented.
+Tracing just-in-time (JIT) compilers record and compile linear control flow paths of operations executed by an interpreter
+inserting operations called guards at points of possible divergence.
+In this paper we describe and analyze how guards work, explaining what concepts
+are used in the intermediate and low-level representation of the JIT
+instructions and how these are implemented.
 
 The goal of this paper is to understand the design constraints when
 implementing guards. Guards have a runtime cost, they take time to execute. On
-the other hand, guards are possible deoptimization points. They need to store
+the other hand, guards are possible deoptimization points, meaning the recorded
+and compiled path has to be left returning control to the interpreter. They need to
+store
 enough information to rebuild the interpreter state.
 Based on the informal observation that guards are among the most common
 operations in the traces produced by RPython's tracing JIT, our
 goal is to present concrete numbers for the frequency and the overhead related
-to guards, explain how they are implemented in the different levels of RPython's
+to guards, explain how they are implemented in the different levels of this particular
 tracing JIT and clarify the rationale behind the design decisions based on the
 numbers provided here.
 
-\cfbolz{this paragraph now suddenly \emph{introduces} guards, despite having talked about them already}
 The operations executed by an interpreter are recorded by the tracing JIT in
 case they are frequently executed (this process is described in more detail in
-Section \ref{sec:Resume Data}). During the recording phase special operations,
-referred to as \texttt{guards}, are inserted into the recorded trace at all
+Section \ref{sec:Resume Data}). During the recording phase \texttt{guards} are
+inserted into the recorded trace at all
 points where the control flow could diverge. As can be seen in
 Figure~\ref{fig:guard_percent} guards account for about 14\% to 22\% of the
-operations before and for about 15\% to 20\% of the operations after the
-optimization pass over the traced and later compiled parts of the benchmarks,
-making guards one of the most common types of operations. Many of these guards
+operations before and for about 15\% to 20\% of the operations after
+optimizing the traces generated for the different benchmarks used in this paper.
+This makes guards one of the most common types of operations. As this paper will show, many of these guards
 fail rarely or not all during execution.
 
 There are several aspects to consider
@@ -168,16 +172,16 @@
 %operations for each benchmark, and the overhead produced by the information
 %stored at the different levels for the guards
 In this paper we want to substantiate the aforementioned observations and
-describe based on them the reasoning behind and the implementation of guards in
+describe based on them the reasoning behind the implementation of guards in
 RPython's tracing just-in-time compiler. the contributions of this paper are:
 \begin{itemize}
-  \item An analysis and benchmark of guards in the context of RPython's tracing Jit.
+  \item An analysis and benchmark of guards in the context of RPython's tracing JIT.
   %An analysis of guards in the context of RPython's tracing JIT to
   %substantiate the aforementioned observation, based on a set of benchmarks,
   \item detailed measurements about the frequency and the
   overhead associated with guards, and
   \item a description about how guards are implemented in the high\-
-  and low-level parts of the JIT and describe the rationale behind the design.
+  and low-level components of the JIT and describe the rationale behind the design.
 \end{itemize}
 
 \begin{figure}
@@ -191,7 +195,7 @@
 and its meta-tracing JIT. Based on these concepts in Section~\ref{sec:Resume
 Data} we proceed to describe for RPython's tracing JIT the details of guards in
 the frontend\bivab{better term for this?} related to recording and storing the
-information required to restore the interpreter state in case of a guard
+information required to rebuild the interpreter state in case of a guard
 failure. Once the frontend has traced and optimized a loop it invokes the
 backend to compile the operations to machine code, Section \ref{sec:Guards in
 the Backend} describes the low-level aspects of how guards are implemented in