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

[antocuni at codespeak.net]

Author: antocuni
Date: Mon Apr  6 14:50:24 2009
New Revision: 63717

Modified:
   pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex
   pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex
   pypy/extradoc/talk/icooolps2009-dotnet/paper.bib
Log:
adapt che conclusions to the new paper



Modified: pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex	Mon Apr  6 14:50:24 2009
@@ -204,7 +204,7 @@
 at the time it emits the code for the inner loop it exactly knows the
 type of \lstinline{obj}, thus it can remove the overhead of dynamic dispatch
 and inline the method call.  Moreover, since \lstinline{obj} never escapes the
-function, it is \emph{virtualized} and its field \lstinline{value} is stored
+function, the allocation is avoided and its field \lstinline{value} is stored
 as a local variable.  As a result, the generated code turns out to be a simple loop
 doing additions in-place.
 

Modified: pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex	Mon Apr  6 14:50:24 2009
@@ -1,6 +1,8 @@
 \section{Related Work}
 
-Promotion is a concept that we have already explored in other contexts. Psyco is
+Flexswitches are closely related to the concept of \emph{promotion}, as
+described by \cite{PyPyJIT}, \cite{PyPyJIT09}.
+Psyco is
 a run-time specialiser for Python that uses promotion (called ``unlift'' in
 \cite{DBLP:conf/pepm/Rigo04}). However, Psyco is a manually written JIT, is
 not applicable to other languages and cannot be retargetted.
@@ -16,8 +18,8 @@
 generator less urgent.  However so far tracing JITs have less general
 allocation removal techniques, which makes them get less speedup in a dynamic
 language with boxing.  Another difference is that tracing JITs concentrate on
-loops, which makes them produce a lot less code.  This issue will be addressed
-by future research in PyPy.
+loops, which makes them produce a lot less code.  This issue is being addressed
+by current research in PyPy \cite{PyPyTracing}.
 
 The code generated by tracing JITs code typically contains guards; in recent research
 \cite{gal_incremental_2006} on Java, these guards' behaviour is extended to be
@@ -25,34 +27,26 @@
 language (JavaScript), by Tamarin\footnote{{\tt
 http://www.mozilla.org/projects/tamarin/}} and in \cite{chang_efficient_2007}.
 
-There has been an enormous amount of work on partial evaluation for compiler
-generation. A good introduction is given in \cite{Jones:peval}. However, most of
-it is for generating ahead-of-time compilers, which cannot produce very good
-performance results for dynamic languages.
-
-However, there is also some research on runtime partial evaluation. One of the
-earliest examples is Tempo for C
-\cite{DBLP:conf/popl/ConselN96,DBLP:conf/dagstuhl/ConselHNNV96}. However, it is
-essentially an offline specializer ``packaged as a library''; decisions about
-what can be specialized and how are pre-determined.
-
-Another work in this direction is DyC \cite{grant_dyc_2000}, another runtime
-specializer for C.  Specialization decisions are also pre-determined, but
-``polyvariant program-point specialization'' gives a coarse-grained equivalent
-of our promotion.  Targeting the C language makes higher-level specialization
-difficult, though (e.g.\ \texttt{mallocs} are not removed).
-
-Greg Sullivan introduced "Dynamic Partial Evaluation", which is a special
-form of partial evaluation at runtime \cite{sullivan_dynamic_2001} and describes
-an implementation for a small dynamic language based on lambda calculus. This
-work is conceptually very close to our own.
-% XXX there are no performance figures, we have no clue how much of this is
-% implemented. not sure how to write this
-
-Our algorithm to avoid allocation of unneeded intermediate objects fits into
-the research area of escape analysis: in comparison to advanced techniques
-\cite{Blanchet99escapeanalysis}, \cite{Choi99escapeanalysis} our algorithm is
-totally simple-minded, but it is still useful in practise.
+IronPython and Jython are two popular implementations of Python for,
+respectively, the CLI and the JVM, whose approach differs fundamentally from
+PyPy.  The source code of PyPy contains a Python interpreter, which the JIT
+compiler is automatically generated from: the resulting executable contains
+both the interpreter and the compiler, so that it is possible to compile only
+the desired parts of the program.  On the other hand, both IronPython and
+Jython implements only the compiler: both compile code lazily (when a Python
+module is loaded), but since they do not exploit the extra information
+potentially available at runtime, it is more a delayed static compilation than
+a true JIT one.  As a result, they run Python programs much slower than their
+equivalent written in
+C\#\footnote{http://shootout.alioth.debian.org/gp4/\\benchmark.php?test=all\&lang=iron\&lang2=csharp}
+or
+Java\footnote{http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/}.
+
+The \emph{Dynamic Language Runtime}\footnote{http://www.codeplex.com/dlr}
+(DLR) is a library designed to ease the implementation of dynamic languages
+for .NET: IronPython is based on the DLR, so the same remarks apply.
+
+\anto{XXX: please review the last two paragraphs}
 
 \section{Conclusion and Future Work}
 
@@ -75,8 +69,6 @@
 code, as tracing JITs do \cite{gal_hotpathvm_2006}.  By compilining whole
 loops at once, the backends should be able to produce better code than today.
 
-\anto{XXX: cite the pypy tracing paper}
-
 At the moment, some bugs and minor missing features prevent the CLI JIT
 backend to handle more complex languages such as Python and Smalltalk.  We are
 confident that once these problems will be fixed, we will get performance

Modified: pypy/extradoc/talk/icooolps2009-dotnet/paper.bib
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/paper.bib	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/paper.bib	Mon Apr  6 14:50:24 2009
@@ -236,3 +236,9 @@
 	author = {Davide Ancona and Carl Friedrich Bolz and Antonio Cuni and Armin Rigo},
 	year = {2009},
 }
+
+ at Article{PyPyTracing,
+ author = {Carl Friedrich Bolz and Antonio Cuni and Armin Rigo and Maciej Fijalkowski},
+ title = {Tracing the Meta-Level: PyPy's Tracing JIT Compiler},
+ journal = {\emph{Submitted to} ICOOOLPS'09},
+ }