[pypy-svn] rev 1762 - pypy/trunk/doc/funding

[arigo at codespeak.net]

Author: arigo
Date: Sun Oct 12 15:10:41 2003
New Revision: 1762

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
Log:
More text about Psyco


Modified: pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
==============================================================================
--- pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	(original)
+++ pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	Sun Oct 12 15:10:41 2003
@@ -73,6 +73,10 @@
 
 The Phase 2 is concerned about research and integration of research, based on the extreme flexibility provided by the PyPy platform.
 
+
+Performance
++++++++++++
+
 Part of Phase 2 focuses essentially on performance issues, which are important in helping to establish a language implementation, and to open the language to a wide range of applications for which it were previously thought to be unsuitable.
 
 The flexibility in PyPy allows a number of designs to be reconsidered; better yet, it allows different design decisions to coexist. Indeed, most "hard" issues in interpreters have no obvious best solution; they are all depend in complicated ways to the specific details of the runtime environment and on the particular application considered and its possibly evolving context. PyPy will provide a good platform to experiment with and compare empirically several different implementations for many of these issues. For example:
@@ -85,11 +89,15 @@
 
 o Generating Continuation Passing Style (CPS) low-level code. This makes the advanced notion of continuation available for the programmer; but -- most importantly in our case -- it allows the development, with the help of an appropriate runtime system, to support massive parallelism. Indeed, in almost any OS, native threads are not appropriate for massive usage. Applications (e.g. web servers handling thousands of connections) have to somehow emulate parallelism explicitely. Soft-threads are an ideal target for language integration. This work (also part of WP07_) would consist of exploiting this idea, which has been first tried for Python in the Stackless project.
 
-o Generating a JIT compiler. Existing work in the Psyco project has shown that it would actually be possible to mostly generate a JIT compiler instead of having to write it from scratch. The basic idea is again abstract interpretation: we replace the "standard" Object Space with an Object Space which, instead of actually performing any operation between two objects, *generates* machine code that can perform the required operation. Again, no change to the bytecode interpreter is needed; all we need is an Object Space able to translate individual operations to processor instructions, and supporting runtime systems. This is defined by WP08_.
+o Generating a JIT compiler. Existing work in the Psyco project has shown that it would actually be possible to mostly generate a JIT compiler instead of having to write it from scratch. The basic idea is again abstract interpretation: instead of actually performing any operation between two objects, we *generate* machine code that can perform the required operation. Again, no change to the bytecode interpreter is needed; all we need is to translate individual operations to processor instructions, together with a supporting runtime systems. This is defined by WP08_.
+
+In dynamic languges, the truth behind JIT compiling is a bit more involved than the above paragraph suggests. All the "standard" operations in Python, including the intuitively simple ones, are actually relatively complex because they depend heavily on the runtime type of the involved objects. This complex code is already written in detail in the "standard" Object Space. Thus the JIT compiler will work by abstract interpretation of RPython code, i.e. abstract interpretation of the interpreter itself (as opposed to user application code). This is similar to the ideas behind the translator, which operates on the RPython source (i.e. the bytecode interpreter and the standard Object Space). We plan to write the dynamic part of the JIT as a plug-in to the translator: instead of generating C code that is the direct translation of PyPy, we will generate C code that itself generates machine code. This extra indirection has large benefits: the operations the JIT need to be taught about are only the ones allowed in RPython. The resulting piece of C code would thus be the JIT-enabled version of PyPy.
+
 
-These two key optimisations will lead to an efficient JIT-compiling interpreter. Note that some of these optimisations can be implemented either in the original source (e.g. by writing a new Object Space) or equivalently at translation time. We will have to choose which strategy is best on a case-by-case basis.
+Other research aspects
+++++++++++++++++++++++
 
-Finally, another part of Phase 2 focuses on non-performance-oriented but research-level aspects. These are the extensions enabled by the flexible division (bytecode compiler, bytecode interpreter, Object Spaces, and translator) enabled in Phase 1. For example, it would be possible to write an interpreter for a completely different language (e.g. Prolog) using the same framework, leveraging the translator and thus obtaining an efficient JIT-enabled implementation with little efforts. (Doing so for the Prolog language has been adopted as an implementation strategy in a current EU-funded project.)
+The other part of Phase 2 focuses on non-performance-oriented research-level aspects. These are the extensions enabled by the flexible division (bytecode compiler, bytecode interpreter, Object Spaces, and translator) enabled in Phase 1. For example, it would be possible to write an interpreter for a completely different language (e.g. Prolog) using the same framework, leveraging the translator and thus obtaining an efficient JIT-enabled implementation with little efforts. (Doing so for the Prolog language has been adopted as an implementation strategy in a current EU-funded project.)
 
 In the context of the PyPy project, we will not replace the interpreter altogether, but experiment with extensions: