[pypy-commit] extradoc extradoc: rewrite conclusion/related work a bit
cfbolz
noreply at buildbot.pypy.org
Fri Aug 10 17:40:21 CEST 2012
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}
More information about the pypy-commit
mailing list