[pypy-svn] r60593 - pypy/extradoc/talk/ecoop2009

[antocuni at codespeak.net]

Author: antocuni
Date: Fri Dec 19 15:24:24 2008
New Revision: 60593

Removed:
   pypy/extradoc/talk/ecoop2009/jitstrategy.tex
Modified:
   pypy/extradoc/talk/ecoop2009/clibackend.tex
   pypy/extradoc/talk/ecoop2009/intro.tex
   pypy/extradoc/talk/ecoop2009/jitgen.tex
   pypy/extradoc/talk/ecoop2009/main.tex
Log:
remove the jitstrategy section and integrate its contents into the introduction.



Modified: pypy/extradoc/talk/ecoop2009/clibackend.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/clibackend.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/clibackend.tex	Fri Dec 19 15:24:24 2008
@@ -1,4 +1,5 @@
 \section{CLI backend for Rainbow interpreter}
+\label{sec:clibackend}
 
 %\subsection{Promotion on CLI}
 %

Modified: pypy/extradoc/talk/ecoop2009/intro.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/intro.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/intro.tex	Fri Dec 19 15:24:24 2008
@@ -79,29 +79,69 @@
 
 \subsection{PyPy and JIT-Generation}
 
-This section will give a high-level overview of how the JIT-generation process
-works. More details will be given in subsequent sections.
-
-- write an interpreter
-- add some hints to the interpreter
-
-translation time:
-- start the translation process, flow graphs
-- run a binding-time analysis using the hints, to figure out ...
-- turn the flow graphs into rainbow bytecode
-- turn the flow graphs of the rainbow interpreter and the original flow graphs
-into .NET code
-
-runtime:
-when the interpreter is started and a function should be interpreted:
- - the generated JIT starts compiling the function 
- - it produces .NET bytecode until it does not have enough information to
- continue. then it stops the compilation and puts a callback into the compiler
- into the generated bytecode.
- - at this point the .NET bytecode that is produced so far is executed.
- - when the callback into the compiler is hit, execution stops and compilation
- starts again
- - afterwards execution continues after the callback (running the code that was
- newly produced)
-
-
+One of the most important aspects that PyPy's translation toolchain can weave
+in is the \emph{automatic generation of a JIT compiler}.  This section will
+give a high-level overview of how the JIT-generation process works. More
+details will be given in subsequent sections.
+
+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 get best performances, 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
+as \emph{hints}, as described in section \ref{sec:hints}.
+
+It is important to distinguish between three distinct phases of execution:
+
+\begin{enumerate}
+\item \textbf{Translation-time}: when the translation toolchain runs and the
+  JIT compiler is automatically generated from the interpreter.  The result is
+  an executable that can be used to run programs written in the chosen
+  language.
+\item \textbf{Compile-time}: when the JIT compiler runs, generating executable
+  code on the fly.
+\item \textbf{Runtime}: when the code generated at compile-time is executed.
+\end{enumerate}
+
+Note that in this schema translation-time happens only once, on the
+developer's machine.  By contrast, compile-time and runtime happens every time
+the user wants to run some program.
+
+
+\subsection{Effective JIT compilation of dynamic languages}
+
+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.
+
+Most JIT compilers for dynamic languages around (such as IronPython, Jython,
+JRuby \anto{XXX insert some reference}) compile code at the method
+granularity.  If on 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 their behaviour
+depends on informations that are not available at compile-time, because
+e.g. the global state of the program can change at runtime. \anto{e.g., we can
+  add/remove methods to classes, etc. Should we insert some example here?}
+
+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.  
+
+Later, when the generated code is executed, the callback is hit and the JIT
+compiler is restarted again.  At this point, the JIT knows exactly the state
+of the program and can exploit all this extra knowledge to generate highly
+efficient code.  Finally, the old code is patched and linked to the newly
+generated code, so that the next time the JIT compiler will not be invoked
+again.  As a result, \textbf{runtime and compile-time are continuously
+  intermixed}.
+
+Modifying the old code to link the newly generated one is very challenging on
+.NET, as the framework does not offer any primitive to do this.  Section
+\ref{sec:clibackend} explains how it is possible to simulate this behaviour.

Modified: pypy/extradoc/talk/ecoop2009/jitgen.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/jitgen.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/jitgen.tex	Fri Dec 19 15:24:24 2008
@@ -221,6 +221,7 @@
 \end{itemize}
 
 \subsection{Hints}
+\label{sec:hints}
 
 Our goal in designing our approach to binding-time analysis was to
 minimize the number of explicit hints that the user must provide in

Modified: pypy/extradoc/talk/ecoop2009/main.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/main.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/main.tex	Fri Dec 19 15:24:24 2008
@@ -83,7 +83,6 @@
 \input{abstract}
 \input{intro}
 \input{tlc}
-\input{jitstrategy}
 \input{jitgen}
 \input{rainbow}
 \input{clibackend}