[pypy-commit] extradoc extradoc: attempt at a different introduction

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4595:ab7e8446d6d7
Date: 2012-08-15 13:51 +0200
http://bitbucket.org/pypy/extradoc/changeset/ab7e8446d6d7/

Log:	attempt at a different introduction

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -127,45 +127,41 @@
 \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}
-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.
 
-Our aim is to help 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, meaning the recorded
-and compiled path has to be left returning control to the interpreter. They need
-enough associated information to enable rebuilding 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 this particular
-tracing JIT and clarify the rationale behind the design decisions based on the
-numbers provided here.
+Tracing just-in-time (JIT) compilers record and compile commonly executed
+linear control flow paths consisting of operations executed by an interpreter.
+At points of possible divergence from the traced path operations called guards
+are inserted. Furthermore, type guards are inserted to specialize the trace
+based on the types observed during tracing. In this paper we describe and
+analyze how guards work and explain the concepts used in the intermediate and
+low-level representation of the JIT instructions and how these are implemented.
+This is done in the context of the RPython language and the PyPy project, which
+provides a tracing JIT compiler geared at dynamic language optimization.
 
-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 guards are
-inserted into the recorded trace at all
-points where the control flow could diverge. As can be seen in
+Our aim is to help understand the design constraints when implementing guards
+and to describe the concrete techniques used in the various layers of RPython's
+tracing JIT. All design decisions will be motivated by concrete numbers for the
+frequency and the overhead related to guards.
+
+It is important to handle guards well, because they are very common operations
+in the traces produced by tracing JITs. 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
-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.
+operations before and for about 15\% to 20\% of the operations after optimizing
+the traces generated for the different benchmarks used in this paper. An
+additional property is that guard failure rates are very uneven. The majority
+of guards never fail at all, whereas those that do usually fail extremely
+often.
 
-There are several aspects to consider
-in the design and optimization of guards, the first aspect is that due to the
-large number of guards the memory overhead related to storing the information
-needed for deoptimization should be kept low. A second aspect is that
-successfully checking guards, i.e. not leaving the compiled trace, &#8211; which is
-the common case &#8211; should be a cheap operation to execute favouring the on-trace
-execution speed in contrast to the deoptimization case where the state has to
-be rebuilt using the stored information. These constraints and trade-offs are
-what make the design and optimization of guards an important and non-trivial
-aspect of the low-level design of a tracing just-in-time compiler.
+Besides being common, guards have various costs attached to 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
+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 make the design
+and optimization of guards an important and non-trivial aspect of the low-level
+design 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