[pypy-svn] r63842 - pypy/extradoc/talk/icooolps2009
cfbolz at codespeak.net
cfbolz at codespeak.net
Wed Apr 8 16:59:57 CEST 2009
Author: cfbolz
Date: Wed Apr 8 16:59:57 2009
New Revision: 63842
Modified:
pypy/extradoc/talk/icooolps2009/paper.tex
Log:
try to streamline the beginning of the abstract a bit and kill a sentence that
goes into a bit too much detail about the problem
Modified: pypy/extradoc/talk/icooolps2009/paper.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009/paper.tex (original)
+++ pypy/extradoc/talk/icooolps2009/paper.tex Wed Apr 8 16:59:57 2009
@@ -79,16 +79,14 @@
\begin{abstract}
We attempt to use the technique of Tracing JIT Compilers
-(see e.g.\ \cite{andreas_gal_incremental_2006}) in the context
+\cite{gal_hotpathvm:effective_2006, andreas_gal_incremental_2006,
+mason_chang_efficient_2007} in the context
of the PyPy project, \ie on programs that are interpreters for some
-dynamic language (including Python). Tracing JIT compilers can greatly
+dynamic languages, including Python. Tracing JIT compilers can greatly
speed up programs that spend most of their time in loops in which they
take similar code paths. However, applying an unmodified tracing JIT to
a program that is itself a bytecode interpreter results in very limited
-or no speedup. One of the reasons is that their main loop, \ie the
-bytecode dispatch, always executes different bytecodes and so follows
-different paths.
-
+or no speedup.
In this paper we show how to guide tracing JIT compilers to greatly
improve the speed of bytecode interpreters. One crucial point is to
unroll the bytecode dispatch loop, based on two hints provided by the
More information about the Pypy-commit
mailing list