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

[antocuni at codespeak.net]

Author: antocuni
Date: Tue Jun  9 18:23:43 2009
New Revision: 65700

Modified:
   pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex
   pypy/extradoc/talk/icooolps2009-dotnet/clibackend.tex
   pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex
   pypy/extradoc/talk/icooolps2009-dotnet/paper.tex
Log:
try to incorporate some of the reviewers' comments


Modified: pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/benchmarks.tex	Tue Jun  9 18:23:43 2009
@@ -49,10 +49,14 @@
   been done, so we are actually measuring how good is the code we produced (\emph{JIT 2}).
 \end{enumerate}
 
+The columns \emph{Interp/JIT2} and \emph{JIT2/C\#} measure the speedup of the
+generated code compared to plain interpretation and of the equivalent C\#
+program compared to the generated code, respectively.
+
 Moreover, for each benchmark we also show the time taken by running the
 equivalent program written in C\#.\footnote{The sources for both TLC and C\#
   programs are available at:
-  \texttt{http://codespeak.net/~antocuni/tlc-benchmarks/}}
+  \texttt{http://codespeak.net/$\sim$antocuni/tlc-benchmarks/}}
 
 The benchmarks have been run on a machine with an Intel Pentium 4 CPU running at
 3.20 GHz and 2 GB of RAM, running Microsoft Windows XP and Microsoft .NET
@@ -135,7 +139,7 @@
 than the non-jitted case.  Moreover, it often runs at the same speed as the
 equivalent program written in C\#, being only 1.5 slower in the worst case.
 
-The difference in speed it is probably due to both the fact that the current
+The difference in speed is probably due to both the fact that the current
 CLI backend emits slightly non-optimal code and that the underyling .NET JIT
 compiler is highly optimized to handle bytecode generated by C\# compilers.
 

Modified: pypy/extradoc/talk/icooolps2009-dotnet/clibackend.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/clibackend.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/clibackend.tex	Tue Jun  9 18:23:43 2009
@@ -83,7 +83,7 @@
 solution consists in creating a new method 
 any time a new case has to be added to a flexswitch.
 
-It is important to underline the difference between flow graphs and a methods:
+It is important to underline the difference between flow graphs and methods:
 the first are the logical unit of code as seen by the JIT compiler, each of
 them being concretely implemented by \emph{one or more} methods.
 
@@ -248,7 +248,7 @@
 
 \subsubsection{Implementation of flexswitches}
 
-To implement each flexswitch, the CLI backend creates an instace of a subclass
+To implement each flexswitch, the CLI backend creates an instance of a subclass
 of \lstinline{BaseLowLevelFlexSwitch}: such an instance stores the mapping
 between each value and the corresponding method we want to invoke.  Then, the
 generated code contains a call to the method \lstinline{execute}, which

Modified: pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/conclusion.tex	Tue Jun  9 18:23:43 2009
@@ -5,12 +5,15 @@
 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.
+not applicable to other languages and cannot be retargetted.  Psyco is a 
+good example of how to implement flexswitches for targets that don't have the
+limitations of the CLI.
 
 The idea of promotion is a generalization of \emph{Polymorphic
   Inline Caches} \cite{hoelzle_optimizing_1991}, as well as the idea of using
 runtime feedback to produce more efficient code
-\cite{hoelzle_type_feedback_1994}.
+\cite{hoelzle_type_feedback_1994}.  The main difference between the two is 
+that PICs only works on types, whereas promotion can work on every kind of value.
 
 PyPy-style JIT compilers are hard to write manually, thus we chose to write a
 JIT generator.  Tracing JIT compilers \cite{gal_hotpathvm_2006} also give

Modified: pypy/extradoc/talk/icooolps2009-dotnet/paper.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009-dotnet/paper.tex	(original)
+++ pypy/extradoc/talk/icooolps2009-dotnet/paper.tex	Tue Jun  9 18:23:43 2009
@@ -76,7 +76,7 @@
 
 \begin{abstract}
 The Common Language Infrastructure (CLI) is a virtual machine expressly
-designed for implementing statically typed languages as C\#, therefore
+designed for implementing statically typed languages such as C\#, therefore
 programs written in dynamically typed languages are typically much slower than C\# when executed on .NET.
 
 Recent developments show that \emph{Just In Time} (JIT) compilers can exploit runtime type