[pypy-svn] r63479 - pypy/extradoc/talk/icooolps2009

[antocuni at codespeak.net]

Author: antocuni
Date: Wed Apr  1 12:31:56 2009
New Revision: 63479

Modified:
   pypy/extradoc/talk/icooolps2009/paper.tex
Log:
finish the review



Modified: pypy/extradoc/talk/icooolps2009/paper.tex
==============================================================================
--- pypy/extradoc/talk/icooolps2009/paper.tex	(original)
+++ pypy/extradoc/talk/icooolps2009/paper.tex	Wed Apr  1 12:31:56 2009
@@ -589,19 +589,19 @@
 bit of profiling, the language interpreter behaves in just the same way as
 without a JIT.
 
-When a hot loop in the user program is identified, tracing is started. The
+When a hot user loop is identified, tracing is started. The
 tracing interpreter is invoked to start tracing the language interpreter that is
 running the user program. Of course the tracing interpreter cannot actually
 trace the execution of the C representation of the language interpreter. Instead
 it takes the state of the execution of the language interpreter and starts
 tracing using a bytecode representation of the language interpreter. That means
 there are two "versions" of the language interpreter embedded in the final
-executable of the VM: On the one hand it is there as executable machine code, on
+executable of the VM: on the one hand it is there as executable machine code, on
 the other hand as bytecode for the tracing interpreter. It also means that
 tracing is costly as it incurs exactly a double interpretation overhead.
 
 From then on things proceed like described in Section \ref{sect:tracing}. The
-tracing interpreter tries to find a loop in the user program, if it found one it
+tracing interpreter tries to find a loop in the user program, if it finds one it
 will produce machine code for that loop and this machine code will be
 immediately executed. The machine code is executed until a guard fails. Then the
 execution should fall back to normal interpretation by the language interpreter.
@@ -635,8 +635,15 @@
 \textbf{Trace Trees:} This paper ignored the problem of guards that fail in a
 large percentage of cases because there are several equally likely paths through
 a loop. Just falling back to interpretation in this case is not practicable.
+\sout{
 Therefore we also start tracing from guards that failed many times and produce
 machine code for that path, instead of always falling back to interpretation. 
+}
+\anto{
+Therefore, if we find a guard that fails often enough, we start tracing from
+there and produce efficient machine code for that case, instead of alwayas
+falling back to interpretation.
+}
 
 \textbf{Allocation Removal:} A key optimization for making the approach
 produce good code for more complex dynamic language is to perform escape
@@ -656,6 +663,10 @@
 update the frame object lazily only when it is actually accessed from outside of
 the code generated by the JIT.
 
+\anto{XXX: should we say that virtualizables are very cool, that nobody else
+  does that and that they are vital to get good performaces with python
+  without sacrificing compatibility?}
+
 \section{Evaluation}
 \label{sect:evaluation}
 
@@ -707,6 +718,9 @@
 
 XXX what else?
 
+\anto{I would cite ourselves (maybe the JIT technical report?) and maybe
+  psyco}
+
 \section{Conclusion and Next Steps}
 
 %\begin{verbatim}