[pypy-commit] extradoc extradoc: rewrite conclusion/related work a bit

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4505:d1264ae54229
Date: 2012-08-10 17:40 +0200
http://bitbucket.org/pypy/extradoc/changeset/d1264ae54229/

Log:	rewrite conclusion/related work a bit

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -845,7 +845,7 @@
 \label{sec:Conclusion}
 In this paper we have concentrated on guards, an operation typically found in
 tracing just-in-time compilers and used to denote points of possible control
-flow bifurcation in recorded traces.
+flow divergence in recorded traces.
 We described how, based on the observation that guards are a frequent operation
 in traces and that they do not fail often, guards have been implemented in the
 high and low level components of RPython's tracing JIT compiler.
@@ -854,31 +854,23 @@
 benchmark set to evaluate previous observations and assumptions. Our
 experiments showed that, as previously assumed, guards are a very common
 operation in traces. At the same time guards are associated with a high
-overhead, because for all compiled guards high- and low information needs to be
+overhead, because for all compiled guards information needs to be
 stored to restore the execution state in case of a bail-out. The measurements
 showed that the compression techniques used in PyPy effectively reduce the
 overhead of guards, while it still produces a significant overhead. The results
-also showed that guard failure is a local event, meaning that there are few
-guards that fail at all, and ever fewer that fail very often, validating the
-concept of reducing the overhead of successful guard checks while incurring an
-additional overhead, besides leaving the optimized code, in the case of a
-bailout having to decode the compressed state representation, which on the
-other hand reduces the memory footprint storing data that is seldom used in a
-compact manner.
+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
+successful guard checks as much as possible while paying a higher price in the
+case of bailout due to having to decode compressed state representation.
+The compressed state representation is reduces the memory footprint of rarely
+used data.
 
-\subsection{Future Work}
-% subsection Future Work (end)
-An aspect that requires further investigation is to experimentally validate
-different of the trade-off decisions that went into the design of guard in
-RPython's tracing JIT. Based on the observation that most guards do not fail
-very often or at all while there are many guard and a few fail very often it
+Based on the observation that most guards do not fail very often or at all it
 would be worth exploring if a more aggressive compression scheme for guards
 would be worth the memory saving in contrast to the increased decoding
 overhead. Based on the same observation we would like to explore the concept of
-LuaJIT's sparse snapshots and its applicability to PyPy. Taking the idea of
-data-driven optimization to investigate possible areas of optimization as was
-done here in retrospective to validate a design seems a promising approach in
-the context of tracing JITs.
+LuaJIT's sparse snapshots and its applicability to PyPy.
 
 \section*{Acknowledgements}
 \section*{Appendix}