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

[lac at codespeak.net]

Author: lac
Date: Thu Feb 28 16:29:11 2008
New Revision: 51919

Modified:
   pypy/extradoc/proposal/openjdk-challenge.txt
Log:
Fix grammatical errors/typos.  Rewrite one clunky sentence.  Add one XXX
for a sentence that wasn't clear to me.


Modified: pypy/extradoc/proposal/openjdk-challenge.txt
==============================================================================
--- pypy/extradoc/proposal/openjdk-challenge.txt	(original)
+++ pypy/extradoc/proposal/openjdk-challenge.txt	Thu Feb 28 16:29:11 2008
@@ -16,7 +16,7 @@
 efficient executables.
 
 Currently, the TT of PyPy provides three complete backends that
-generate C code, bytecode for CLI/.NET and bytecode for the JVM.  By
+generate C code, bytecode for CLI/.NET or bytecode for the JVM.  By
 using these backends, we can get Python implementations that run on a
 standard C/Posix environment, on the CLI or on the JVM.
 
@@ -34,14 +34,14 @@
 being potentially much more efficient than all the current other
 alternatives (see the "Related Work" section).
 
-Currently, the PyPy JIT works only in conjunction with the C backend;
-early results are very good, the resulting Python interpreter
-can run numeric intensive computations at roughly the same speed of C,
+Currently, the PyPy JIT works only in conjunction with the C backend.
+Early results are very good. The resulting Python interpreter
+can run numerically intensive computations at roughly the same speed of C,
 as shown by the `technical report`_ on the JIT.
 
 Moreover, there is an experimental JIT backend that emits code for the
-CLI; it is still work in progress and very incomplete, but it shows
-that the it is possible to adapt the PyPy JIT to emit code for object
+CLI; it is still a work in progress and very incomplete, but it shows
+that the is possible to adapt the PyPy JIT to emit code for object
 oriented virtual machines.
 
 
@@ -129,7 +129,8 @@
 is a separate task and it is out of the scope of this proposal; it is
 important to underline that once the JVM backend for the JIT is
 complete, the resulting pypy-jvm will automatically take advantage of
-all the optimizations written for the others backend.
+all the optimizations written for the other backends. XXX expand
+this by one sentence because this is unclear as written
 
 We also expect to find benchmarks in which the JIT that targets the
 MLVM will perform better than the JIT that targets the plain JVM,
@@ -194,17 +195,18 @@
     methods until a call threshold is reached, then it compiles the
     method body to JVM bytecode to be executed from that point on;
     however, even if the compilation is truly just in time, JRuby
-    doesn't exploit type informations that are known only at runtime to
+    doesn't exploit type information that is known only at runtime to
     produce specialized, efficient versions of the function;
 
   - in the .NET world, IronPython works more or less as Jython;
     additionally, it exploits dynamic code generation to implement
     `Polymorphic Inline Caches`_.
 
-PyPy JIT is different of all of these, because runtime and compile
+The PyPy JIT is different from all of these, because runtime and compile
 time are continuously intermixed; by waiting until the very last
 possible moment to emit code, the JIT compiler is able to exploit all
-the runtime informations that wouldn't be available before, e.g. the
+the runtime information, including that which is only available late
+in the process, e.g. the
 exact type of all the variables involved; thus, it can generate many
 specialized, fast versions of each function, which in theory could run
 at the same speed of manually written Java code.