[pypy-svn] r63567 - pypy/extradoc/talk/icooolps2009-dotnet

arigo at codespeak.net arigo at codespeak.net
Fri Apr 3 16:23:36 CEST 2009


Author: arigo
Date: Fri Apr  3 16:23:36 2009
New Revision: 63567

Modified:
   pypy/extradoc/talk/icooolps2009-dotnet/intro.tex
Log:
Try to adapt section 1.2 to avoid repeating from the Introduction.


Modified: pypy/extradoc/talk/icooolps2009-dotnet/intro.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/intro.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/intro.tex	Fri Apr  3 16:23:36 2009
@@ -4,13 +4,16 @@
 
 The alternative is to write a compiler; writing a compiler that targets a high
 level virtual machine like CLI or JVM is easier than targeting a real CPU, but
-it still requires a lot of work, as IronPython, Jython, JRuby demonstrate.
+it still requires a lot of work, as
+IronPython\footnote{http://www.codeplex.com/IronPython},
+Jython\footnote{http://www.jython.org/}
+and JRuby\footnote{http://jruby.codehaus.org/} demonstrate.
 
 Moreover, writing a static compiler is often not enough to get high
-performance; IronPython and JRuby are going in the direction of JIT compiling
-specialized versions of the code depending on the actual values/types seen at
-runtime; this approach seems to work, but writing it manually requires an
-enormous effort.
+performance.  IronPython and JRuby are going in the direction of
+compiling just-in-time (JIT) specialized versions of the code depending
+on the actual values/types seen at runtime; this approach seems to work,
+but writing it manually requires an enormous effort.
 
 PyPy's approach \cite{RiBo07_223} is to automatize the generation of 
 specializing JIT compilers in order
@@ -76,12 +79,23 @@
 give a high-level overview of how the JIT-generation process works. More
 details can be found in \cite{PyPyJIT} and \cite{PyPyJIT09}.
 
-The first step is to write an interpreter for the chosen language.  Since it
+The main difference between the JIT compilers generated by PyPy and the
+ones found in other projects like IronPython is that the latter compile
+code at the method granularity -- if on the one hand they can exploit
+some of the knowledge gathered at runtime (e.g.\ the types of method
+parameters), on the other hand they can do little to optimize most of
+the operations inside, because few assumptions can be made about the
+global state of the program.  The PyPy JITs, on the other hand, work at
+a sub-method granularity, as described next.
+
+When using PyPy, the first step is to write an interpreter for the chosen language.  Since it
 must be fed to the translation toolchain, the interpreter has to be written in
 RPython.  Then, to guide the process, we need to add few manual
 annotations to the interpreter, in order to teach the JIT generator which
-informations are important to know at compile-time.  Annotations are inserted
+information is important to know at compile-time.  Annotations are inserted
 as \emph{hints}, as described in section \ref{sec:hints}.
+From these hints, PyPy will statically generate an interpreter and a JIT
+compiler in a single executable (here a .NET executable).
 
 \anto{maybe we can avoid to talk about hints?}
 
@@ -103,29 +117,21 @@
 the user wants to run some program.
 }
 
-Generating efficient compilers for dynamic languages is hard.  Since these
-languages are dynamically typed, usually the compiler does not have enough
-information to produce efficient code, but instead it has to insert a lot of
-runtime checks to select the appropriate implementation for each operation.
-
-By emitting code at runtime, JIT compilers can exploit some extra knowledge
-compared to traditional static compilers.  However, we need to take special
-care to choose a strategy for JIT compilation that lets the compiler to take
-the best of this advantage.
+\commentout{
+By emitting code at runtime, JIT compilers can exploit extra
+knowledge compared to traditional static compilers -- more than just the
+type of the function arguments.  However, special care is needed to
+choose a strategy for JIT compilation that lets the compiler take the
+best of this advantage.
+}
 
-Most JIT compilers for dynamic languages around (such as
-IronPython\footnote{http://www.codeplex.com/IronPython},
-Jython\footnote{http://www.jython.org/} or
-JRuby\footnote{http://jruby.codehaus.org/}) compile code at the method
-granularity.  If on the one hand they can exploit some of the knowledge
-gathered at runtime (e.g. the types of method parameters), on the other hand
-they can do little to optimize most of the operations inside, because few
-assumptions can be made about the global state of the program.
-
-JIT compilers generated by PyPy solve this problem by delaying the compilation
-until they know all the informations needed to generate efficient code.  If at
-some point the JIT compiler does not know about something it needs, it
-generates a callback into itself and stops execution.  
+The interesting property of the generated JIT compiler is to delay the
+compilation until it knows all the information needed to generate
+efficient code.  In other words, at runtime, when the interpreter notice
+that it is useful to compile a given piece of code, it sends it to the
+JIT compiler; however, if at some point the JIT compiler does not know
+about something it needs, it generates a callback into itself and stops
+execution.
 
 Later, when the generated code is executed, the callback might be hit and the JIT
 compiler is restarted again.  At this point, the JIT knows exactly the state



More information about the Pypy-commit mailing list