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

antocuni at codespeak.net antocuni at codespeak.net
Sun Dec 21 10:50:21 CET 2008

Author: antocuni
Date: Sun Dec 21 10:50:21 2008
New Revision: 60667

fix xxx

Modified: pypy/extradoc/talk/ecoop2009/intro.tex
--- pypy/extradoc/talk/ecoop2009/intro.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/intro.tex	Sun Dec 21 10:50:21 2008
@@ -123,9 +123,9 @@
 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
+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

Modified: pypy/extradoc/talk/ecoop2009/jitgen.tex
--- pypy/extradoc/talk/ecoop2009/jitgen.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/jitgen.tex	Sun Dec 21 10:50:21 2008
@@ -1,7 +1,9 @@
 \section{Automatic generation of JIT compilers}
-Traditional JIT compilers are hard to write, time consuming, hard to evolve,
-etc. etc. \anto{we need a better introductive sentence}
+Traditional JIT compilers are hard to write, time consuming and hard to
+evolve.  On the other hand, interpreters are easy both to write and maintain,
+but they are usually slow.  By automatically generating a JIT compiler out of
+an interpreter, we take the best of both worlds.

More information about the Pypy-commit mailing list