[pypy-svn] r51896 - pypy/extradoc/proposal
lac at codespeak.net
lac at codespeak.net
Wed Feb 27 10:25:03 CET 2008
Author: lac
Date: Wed Feb 27 10:25:02 2008
New Revision: 51896
Modified:
pypy/extradoc/proposal/openjdk-challenge.txt
Log:
Fix typos and minor grammatical errors; whack one extremely clumsy sentence;
and add a few XXX:s for ideas I have for improvement
Modified: pypy/extradoc/proposal/openjdk-challenge.txt
==============================================================================
--- pypy/extradoc/proposal/openjdk-challenge.txt (original)
+++ pypy/extradoc/proposal/openjdk-challenge.txt Wed Feb 27 10:25:02 2008
@@ -9,8 +9,8 @@
we mention other languages implementations?)
PyPy is divided into two main parts: the Python interpreter, which
-implements the Python language and its written in RPython_, and the
-Translation Toolchain (TT), which transforms and translates programs
+implements the Python language and is written in RPython_, and the
+Translation Toolchain (TT), (XXX: written in Python?) which transforms and translates programs
written in RPython into the final executables. RPython is a subset of
Python specifically designed to allow the TT to analyze RPython
programs and translate them into lower level, very efficient
@@ -22,17 +22,18 @@
standard C/Posix environment, on the CLI or on the JVM.
It is important to underline that the job of the TT is not limited to
-the translation into an efficient executable, but it actively
-transform the source interpreter by adding new features and
+translation into an efficient executable, but it actively
+transforms the source interpreter by adding new features and
translation aspects, such as garbage collection, stackless
-capabilities, etc. (XXX: link).
+capabilities, etc. (XXX: link) (XXX: not sure stackless is well known,
+say microthreading instead?? mention proxying or security aspects??).
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.
Currently, the PyPy JIT works only in conjunction with the C backend;
-early results are very good, since the resulting Python interpreter
+early results are very good, the resulting Python interpreter
can run numeric intensive computations at roughly the same speed of C
(XXX: link).
@@ -90,12 +91,16 @@
write completely new code.
If the project goes to completion, the code developed will be
-integrated into the PyPy codebase; if Sun requires to release the code
+integrated into the PyPy codebase; if Sun requires us to release the code
under the SCA (thus sharing the copyright between the original author
and Sun itself), we will send to Sun a document in unified diff format
that extensively shows all and sole lines of code on which Sun will
have the copyright.
+PyPy is already licensed under the extremely permissive MIT license,
+so there are no legal copyright barriers preventing us from sharing
+code in such a way.
+
Project completion
------------------
@@ -126,20 +131,22 @@
Relevance to the community
--------------------------
-Recently the community showed a lot of interests in dynamic languages
-on top of the JVM. Even if right now Jython is the only usable
-implementation of Python for the JVM, PyPy can potentially become the
+Recently the community has shown a lot of interest in dynamic languages
+which run
+on top of the JVM. Even if currently Jython(XXX: link) is the only usable
+implementation of Python for the JVM, PyPy has the potential to become the
reference implementation in the future.
-To have a working JIT for the JVM is an important step to make PyPy
-the fastest Python for the JVM ever. Moreover, due to the innovative
-ideas implemented by PyPy, there are chances that Python could become
-the fastest dynamic language that run on the top of the JVM.
+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 possible (XXX: likely?) that Python could become
+the fastest dynamic language 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
-with the TT; as a proof of concept, PyPy already contains partial
-implementations of Prolog, JavaScript, Scheme and Smalltalk.
+with the TT; as a proof of concept, PyPy already contains
+fairly complete implementations of Prolog and Smalltalk, as well
+as partial implementations of JavaScript and Scheme. (XXX: did I overstate things?)
Since the JIT generator is independent of the Python languages, it
will be possible to automatically add a JIT compiler to every language
@@ -164,15 +171,15 @@
- `this paper`_ shows how this technique is exploited to write an
efficient implementation of EcmaScript which runs on top of the JVM;
- - JRuby also come with a JIT compiler that dynamically translates
- ruby code into JVM bytecode; the difference with the PyPy approach
- is that JRuby doesn't exploit type information that are known only
+ - JRuby also comes with a JIT compiler that dynamically translates
+ Ruby code into JVM bytecode, however, unlike PyPy
+ JRuby doesn't exploit type information that is known only
at runtime to produce specialized, efficient versions of the
function; moreover, while the JRuby JIT is hand-written, the whole
goal of the PyPy JIT generator is to generate it automatically
from the intepreter;
- - in the .NET world, IronPython also emit code dynamically to
+ - in the .NET world, IronPython also emits code dynamically to
optimize hot spots, but not in a pervasive way as JRuby or PyPy.
XXX (arigo) I'm confused by the previous sentence. I thought
More information about the Pypy-commit
mailing list