[pypy-svn] r63682 - pypy/extradoc/talk/ep2009

[arigo at codespeak.net]

Author: arigo
Date: Sun Apr  5 20:27:59 2009
New Revision: 63682

Modified:
   pypy/extradoc/talk/ep2009/abstract.txt
Log:
Fix the XXXes.


Modified: pypy/extradoc/talk/ep2009/abstract.txt
==============================================================================
--- pypy/extradoc/talk/ep2009/abstract.txt	(original)
+++ pypy/extradoc/talk/ep2009/abstract.txt	Sun Apr  5 20:27:59 2009
@@ -1,7 +1,8 @@
 We will give an update on the state of PyPy, the Python
 implementation in Python.
 
-Part 1  - becoming complete - 30 minutes of the projected 1 hour
+
+Part 1 - becoming complete - 30 minutes of the projected 1 hour
 ===============================================================
 
 PyPy has come a long way.  No longer merely a research project and
@@ -10,31 +11,30 @@
 Twisted.  We will focus on the improvements that happened during
 the last year in PyPy, which made this possible.
 
-Thus, even before the JIT work we could assert that PyPy now provides
-a complete, flexible and reasonably fast XXX can we say how fastXXX
-Python Interpreter, itself implemented in Python.  
-
-XXX do we need to mention how we are not complete?  what odd things need
-to be done?  If there are few of them, no, if there are many, yes XXX
+Thus -- even before the JIT work -- we could assert that PyPy
+now provides a complete, flexible and reasonably fast Python
+interpreter, itself implemented in Python.  "Complete" means
+it is fully compliant but misses a lot of third-party
+extension modules; "reasonably fast" still means about 1.5
+to 2 times slower than CPython; and we will give some examples
+of "flexible".
 
 This section of the talk is mostly intended for people who are already
 familiar with the PyPy project, and want an update as to how we are doing.
-We won't be going over old ground, i.e. what is a specialising compiler,
-what is Just-In-Time compilation, and what problems plague those researchers
-attempting to develop a JIT for dynamic languages XXX or blah blah blah more
-stuff you would rather not talk about)
+We will also explain the motivations driving current PyPy developement
+and its targets for the future.
 
 
-Part 2  - becoming fast  30 minutes of the projected 1 hour
+Part 2 - becoming fast - 30 minutes of the projected 1 hour
 ===========================================================
 
 As we write this abstract we are finally integrating our Just-in-Time 
-compiler generator into PyPy.  Preliminary results look *great*.
-XXX can we put in any sort of metrics here? XXX
+compiler generator into PyPy.  Preliminary results look very good
+(more during the talk!).
 
 The PyPy JIT compiler, in addition to being a *specialising* compiler,
-is a *tracing* compiler.  Another example of a tracing compiler is
-JavaScript's TraceMonkey, recently included in
+is now a *tracing* compiler.  Another example of a tracing compiler is
+JavaScript's TraceMonkey, soon to be included in
 FireFox.  We will give the status of the implementation of
 our JIT, with speed measures.
 
@@ -43,15 +43,13 @@
 
 Due to the architecture of PyPy, one can generate such a tracing compiler for 
 *any* computer language, only by writing an interpreter for it.  We already
-have ones for Squeak, Prolog, and XXX am I lying here?? ***  People wishing
+have ones for Squeak, Prolog and GameBoy, and experimental ones for
+JavaScript, Scheme, etc. so people wishing
 to speed up other languages now have a clear and simple path to follow.
 
-Also due to our architecture we can generate code for the JVM, .NET  and
-XXX do we have a C version working now?? ***. 
-
+Also due to our architecture we can generate code for C but also for the
+JVM and .NET; it is possible to generate a JIT for these platforms too,
+running on top of the platform's native JIT.
 
-This talk will also explain the
-motivations driving current PyPy developement and its targets
-for the future.
 
 Authors: antocuni, cfbolz, arigo