[pypy-svn] r51992 - pypy/extradoc/proposal

[cfbolz at codespeak.net]

Author: cfbolz
Date: Sat Mar  1 13:50:21 2008
New Revision: 51992

Modified:
   pypy/extradoc/proposal/openjdk-challenge.txt
Log:
fix a few things, add two XXXs


Modified: pypy/extradoc/proposal/openjdk-challenge.txt
==============================================================================
--- pypy/extradoc/proposal/openjdk-challenge.txt	(original)
+++ pypy/extradoc/proposal/openjdk-challenge.txt	Sat Mar  1 13:50:21 2008
@@ -26,11 +26,11 @@
 such as garbage collection, microthreading (like `Stackless Python`_),
 etc.
 
-The most exciting feature of the TT is the ability to automatically
-turn the interpreter into a JIT compiler that exploits partial
-evaluation techniques to dynamically generate efficient code.  The
+The most exciting feature of the TT is the ability apply partial evaluation
+techniques to automatically turn the interpreter into a JIT compiler which
+generates efficient code dynamically.  The (XXX not so novel: hotspot does it too)
 novel idea behind PyPy JIT is to delay the compilation until we know
-all the informations useful for emitting optimized code, thus
+all the information useful for emitting optimized code, thus
 being potentially much more efficient than all the current other
 alternatives (see the "Related Work" section).
 
@@ -109,7 +109,7 @@
 Project completion
 ------------------
 
-PyPy JIT is still under heavy development; potentially, the resulting
+The PyPy JIT is still under heavy development; potentially, the resulting
 JIT compiler will be able to optimize a large number of Python
 programs, but at the moment it gives the best results only with
 computational intensive functions that use only operations between
@@ -125,11 +125,12 @@
 JIT support, it runs roughly at the same speed as its C equivalent
 compiled with `gcc -O0`.
 
-Making the Python interpreter to exploit the full potential of the JIT
-is a separate task and since it requires some small changes to the
+Supporting and thus speeding up more parts of the Python language
+is a separate task and since it requires changes to the
 interpreter, it is out of the scope of this proposal. It is important
-to underline that once the PyPy interpreter is fully optimized for the
-JIT, PyPy for the JVM will automatically take advantage of these speed
+to underline that this work is independent from the backend being used,
+so once the PyPy interpreter is fully optimized for the
+JIT, PyPy for the JVM will automatically take advantage of these improvements
 ups, without needing to change the JIT backend for the JVM.
 
 We also expect to find benchmarks in which the JIT that targets the
@@ -145,11 +146,13 @@
 languages which run on top of the JVM.  Even if currently Jython_ is
 the only usable implementation of Python for the JVM, PyPy has the
 potential to become the reference implementation in the future.
+(XXX careful: this enters politics country, I guess we don't want to piss of the
+Jython people)
 
 To have a working JIT for the JVM is an important step towards making PyPy
 the fastest Python for the JVM, ever.  Moreover, due to the innovative
 ideas implemented by PyPy, it is likely that Python could become
-the fastest dynamic language that runs on the top of the JVM.
+the fastest dynamic language of its class that runs on the top of the JVM.
 
 Finally, PyPy is not limited to Python: it is entirely possible to
 write interpreters for languages other than Python and translate them
@@ -160,7 +163,7 @@
 Since the JIT generator is independent of the Python languages, it
 will be possible to automatically add a JIT compiler to every language
 written using the PyPy TT; thus, PyPy could become a very attractive
-platform to develop dynamic languages for the JVM.
+environment to develop dynamic languages for the JVM.
 
 
 Dependencies on Sun
@@ -187,7 +190,7 @@
     really works ahead of time (AOT), because the code is fully
     emitted before the program starts, and it doesn't exploit
     additional informations that would be available only at runtime
-    (e.g., informations about the types that each variable can
+    (most importantly informations about the types that each variable can
     assume);
 
   - JRuby supports interpretation, AOT compilation and JIT
@@ -212,7 +215,7 @@
 at the same speed of manually written Java code.
 
 Moreover, the JIT compiler is automatically generated by the TT: we
-believe, based on previous experiences as Psyco_, that manually
+believe, based on previous experiences with Psyco_, that manually
 writing a JIT compiler of that kind is hard and error prone,
 especially when the source language is as complex as Python; by
 writing a JIT compiler generator, we get JIT compilers that are