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

pedronis at codespeak.net pedronis at codespeak.net
Thu Oct 9 00:22:30 CEST 2003


Author: pedronis
Date: Thu Oct  9 00:22:28 2003
New Revision: 1637

Modified:
   pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
added draft for Current State of the Art

some of the things on Psyco may make no sense, sorry for that.



Modified: pypy/trunk/doc/funding/B1.0_objectives.txt
==============================================================================
--- pypy/trunk/doc/funding/B1.0_objectives.txt	(original)
+++ pypy/trunk/doc/funding/B1.0_objectives.txt	Thu Oct  9 00:22:28 2003
@@ -31,8 +31,6 @@
 
 B.1.4 Beyond State of The Art
 
-
-
 Scientific and technological objectives of the project & state of the art
 ===============================================================================
 
@@ -111,10 +109,6 @@
 C-implementation. We expect algorithmic code to run at least at 50% of
 the speed of pure, optimized C code.
 
-
-
-
-
 :DELETE:BEGIN
 
 For dynamic languages, for which whole-program static compilation is
@@ -155,6 +149,8 @@
 * logic programming, 
 * aspect-oriented programming
 
+!!! reuse some of this:
+
 Our goal is to attack both the performance and flexibility problems at
 the same time, by reimplementing/capturing the semantics of Python in
 itself (a subset thereof), central to this is the concept of Object
@@ -181,7 +177,76 @@
 Current State of The Art
 ------------------------------
 
-empty
+Haskell monadic modular interpreters [popl95.ps.gz][dsl.ps.gz] are a
+researched attempt at achieving modularity for interpreters. They have
+not been tried on something as large as Python, as approach it is hard
+to relate to for programmers accustomed to more conventional OO
+programming and requires sophisticated partial evaluation to remove the
+monadic overhead.
+
+Our Object Spaces should allow customization with OO techniques, they
+will encapsulate the object operation semantics, creation and global
+state of all objects. Monad transformers can be used also to
+modularize continuation passing, exceptions and other control flow
+aspects. We expect to encapsulate those in an interpreter loop to be
+also translated or to implement them as aspects weaved in by the
+translation process, for example producing CPS code.
+
+In its basics the approach of writing a language interpreter in the
+language itself (a subset thereof) and then producing a running
+low-level code version trough a translation process has already been
+taken, e.g. for the Scheme (Scheme 48)[kelsey97prescheme.pdf] and the
+Smalltalk (Squeak) [OOPSLA.Squeak.html] languages. Obtaining in this
+way an interpreter comparable with current C Python implementation is
+within current state of the art, but successively we plan to exploit
+the gained flexibility much further, separating concerns between the
+translator, the code and Object Spaces encapsulating the core language
+and its semantics and further pluggable modules for both.
+
+JIT compilers have been reasonably well studied; an account of their
+history is given in [jit-history.pdf]. But actually writing a JIT for
+a given language is generally a major task [oopsla-vm-wkshp.pdf].
+Different techniques to ease this path have been recently explored;
+let us cite:
+
+* to implement a dynamic language in a flexible way, it can be written
+  on top of another one, e.g. as a dynamic translator that produces
+  bytecodes for an existing virtual machine. If the virtual machine is
+  already equipped with state-of-the-art JIT compilation, it is
+  possible to leverage its benefits to the new language. This path is
+  not only much shorter than designing a complete custom JIT, but it
+  is also easier to maintain and evolve. This idea is explored for the
+  Self virtual machine in [oopsla-vm-wkshp.pdf].  As pointed out in
+  that paper, some source language features may not match any of the
+  target virtual machine features. When this issue arises, we are
+  left with the hard problem of refactoring an efficient JIT-based
+  virtual machine.  
+
+* a completely different approach: making it easier to derive a JIT
+  from an existing C interpreter. DynamoRIO instrumentates the
+  execution of compiled programs and optimizes them dynamically. It
+  has been extended with specific support for interpreters. With
+  minimal amounts of changes in the source of an interpreter, it can
+  significantly reduce the processor-time interpretative overhead
+  [ivme03.pdf]. While this offers a highly competitive gain/effort
+  ratio, performance does not reach the levels of a hand-crafted JIT.
+
+Current Python C implementation (CPython) is a straight-forward bytecode
+interpreter. Psyco [psyco] XXX [ucpy-reverse-engineering-python.pdf] is
+an extension to it implementing a prototype JIT.
+
+Psyco is more precisely a specializing JIT compiler based on abstract
+interpretation. It specializes on values using heuristics not to be
+over-eager. It gathers statistics to applies itself only on often
+executed code and performs well for algorithmic code and built-in
+types. It would likely benefit from integration with type-feedback
+techniques as developed for Self [hlzle91optimizing.pdf]
+[reconciling-responsiveness-with-performance.pdf] to deal more
+effectively with (highly) polymorphic call-sites.
+
+In its current incarnation it is also a delicate hand-crafted piece
+of code, which is hard to maintain. But this should not inherently be the
+case.
 
 Beyond State of The Art
 -----------------------------


More information about the Pypy-commit mailing list