[pypy-svn] rev 1796 - pypy/trunk/doc/funding
anna at codespeak.net
anna at codespeak.net
Sun Oct 12 20:03:19 CEST 2003
Author: anna
Date: Sun Oct 12 20:03:18 2003
New Revision: 1796
Modified:
pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
I've done some proofreading and editing. Some minor proofing changes (commas, etc), and one larger change moving most of a paragraph on our Object Spaces down to the Beyond State of the Art, where it fit better. Anna
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 Sun Oct 12 20:03:18 2003
@@ -8,7 +8,7 @@
Current language implementations are static and hard to modify by
users. Even the implementations of open-source dynamic languages have
non-flexible designs crafted by a small group of developers. While
-designing a good programming language is no easy task often
+designing a good programming language is no easy task, often
application developers seek more support and configurability of their
language. This is especially the case for the rising number of
specialized runtime environments where small memory footprints,
@@ -32,17 +32,16 @@
In the long run, user pressure tends to shape interpreters towards
performance at the expense of other aspects (simplicity, flexibility),
-possibly culminating with the introduction of a native JIT, adding a
-significant amount of code and complexity and further impairing the
-flexibility. [S03]_
+possibly culminating in the introduction of a native 'Just-In-Time' (JIT)
+compiler, adding a significant amount of code and complexity and further
+impairing the flexibility. [S03]_
Consequently, application developers are often left with bad choices
-not only for productivity versus performance, but they have to work
-around the hard-wired characteristics built into the
-languages. Instead they would like to adapt and configure a VHLL to
-suit their needs while at the same time developing on top of a custom
-but standardised language offering both productivity and performance.
-
+not only regarding productivity versus performance, but they have to work
+around hard-wired characteristics built into the languages. Instead they
+would like to adapt and configure a VHLL to suit their needs while at the same
+time developing on top of a custom but standardized language offering both
+productivity and performance.
Quantified specific objective
-----------------------------------
@@ -55,12 +54,12 @@
bytecode interpreter. A number of features, most of which are hard to
implement as application-level libraries, can become part of the
language in a manageable and user-configurable way if they are
-implemented modularily as Object Spaces. For example:
+implemented modularly as Object Spaces. For example:
* choice of memory and threading model
* choice of speed vs. memory trade-offs
* distributed/parallel execution (SMP or Networked)
-* orthogonal persistency
+* orthogonal persistence
* pervasive security support
* logic and aspect-oriented programming
@@ -68,88 +67,79 @@
VHLL language (Python itself) and recover performance with a separate
translation process producing specialized efficient low-level code. The
translation is not one-shot: it can be repeated and tailored to weave
-different aspects into releases with different trade-offs and features,
+different aspects into releases with different trade-offs and features,
giving the user of the language a real choice.
-
-The PyPy project plans to deliver a compliant language implementation
-passing all relevant (at least 90%) unit-tests of the current reference
-C-implementation. Moreover, we will be able to add techniques such as
-Just-In-Time compilation without making the interpreter more complex.
-Thus we will get speed increases of 2-10 times over the reference
-C-implementation. We expect algorithmic code to run at least at 50% of
-the speed of pure, optimized C code.
+The PyPy project plans to deliver a compliant language implementation
+passing all unit-tests of the current reference C-implementation that are
+relevant to the new one. At least 90% of existing unit tests will be directly
+applicable. Moreover, we will be able to add techniques such as JIT compilation
+without making the interpreter more complex. Thus we will get speed increases of
+2-10 times over the reference C-implementation. We expect algorithmic code to
+run at least at 50% of the speed of pure, optimized C code.
Current State of The Art
------------------------------
Haskell monadic modular interpreters [LHJ95]_ [H98]_ 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.
+not been tried on something as large as Python, however, as the approach is hard
+to relate to for programmers accustomed to more conventional Object-Oriented
+(OO) programming and requires sophisticated partial evaluation to remove the
+monadic overhead. Monad transformers can also be used to modularize
+continuation passing, exceptions and other control flow aspects.
-In its basics the approach of writing a language interpreter in the
+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) [K97]_ and the
Smalltalk (Squeak) [IKM97]_ 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
+within current state of the art, but 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 [A03]_ . But actually writing a JIT for
+history is given in [A03]_ . But actually writing a JIT compiler for
a given language is generally a major task [WAU99]_ .
-Different techniques to ease this path have been recently explored;
-let us cite:
+Different techniques to ease this path have been recently explored:
-* to implement a dynamic language in a flexible way, it can be written
+* 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
+ not only much shorter than designing a complete custom JIT compiler, but it
is also easier to maintain and evolve. This idea is explored for the
Self virtual machine in [WAU99]_ . 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.
+ left with the hard problem of refactoring an efficient JIT compiler-based
+ virtual machine.
-* a completely different approach: making it easier to derive a JIT
- from an existing C interpreter. DynamoRIO instrumentates the
+* Using a completely different approach, to make it easier to derive a JIT
+ compiler from an existing C interpreter, DynamoRIO instruments 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
[S03]_ . While this offers a highly competitive gain/effort
- ratio, performance does not reach the levels of a hand-crafted JIT.
+ ratio, performance does not reach the levels of a hand-crafted JIT compiler.
The current Python C implementation (CPython) is a straight-forward bytecode
interpreter. Psyco [R03]_ is an extension to it implementing a highly
-experimental [APJ03]_ specializing JIT compiler based on abstract interpretation.
-In its current incarnation it is also a delicate hand-crafted piece
-of code, which is hard to maintain and not flexible. But this should not
+experimental [APJ03]_ specializing JIT compiler based on abstract
+interpretation. In its current incarnation it is also a delicate hand-crafted
+piece of code, which is hard to maintain and not flexible. But this should not
inherently be the case. Moreover it would likely benefit from integration
-with type-feedback techniques as developed for Self [HCU91]_ [HU94]_.
+with type-feedback techniques such as those developed for Self [HCU91]_ [HU94]_.
Beyond State of The Art
-----------------------------
-Our architecture is based on Object Spaces, and translation. The
+Our architecture is based on Object Spaces and translation. The
interpreter's main dispatch loop handles control flow and supporting
data structures (frame stack, bytecode objects...); each individual
operation on objects is dispatched to the object space.
@@ -166,9 +156,17 @@
Spaces, other modules also translated, or the pluggable behavior of
the translation itself.
+Object Spaces, in contrast to monadic interpreters, will allow customization
+with OO techniques, as they encapsulate the object operation semantics, creation
+and global state of all objects. As mentioned above, monad transformers can be
+used 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 of the translation process,
+for example, producing continuation-passing code.
+
Many of these aspects are really cross-cutting concerns in the
-original AOP sense. In general our approach relates to the seminal
-AOP ideas in [KLM97]_, although they have not been
+original Aspect Oriented Programming (AOP) sense. In general our approach
+relates to the seminal AOP ideas in [KLM97]_, although they have not been
used on interpreters for large practical languages. The subset of
Python in which we express the core interpreter and Object Spaces is
the component language in the terminology of the paper, while the
@@ -194,13 +192,13 @@
Another key innovative aspect of our project is to generate the JIT
compiler instead of writing it manually. Indeed, although Psyco was
hand-written, large parts have a one-to-one correspondence to whole
-sections of the CPython interpreter. This is uncommon for JITs, but
+sections of the CPython interpreter. This is uncommon for JIT compilers, but
Psyco's good results give ample proof-of-concept. (This property can be
-explicitely related to the DynamoRIO project cited above, which
-instrumentates the interpreter itself.) The one-to-one correspondence
+explicitly related to the DynamoRIO project cited above, which
+instruments the interpreter itself.) The one-to-one correspondence
between parts of CPython and Psyco is as follows: to each expression in
the source of CPython corresponds a more complex expression in Psyco,
-which does instrumentation and optimisations. Our plan is thus to
+which does instrumentation and optimizations. Our plan is thus to
generate automatically as much of the JIT as possible, by changing the
translator to generate instrumenting/optimizing C instructions instead
of (or in addition to) the normal C instructions that would be the
@@ -214,9 +212,9 @@
References:
-.. [S03] Gregory Sullivan et. al., "Dynamic Native Optimization of Native Interpreters". IVME 03. 2003.
- http://www.ai.mit.edu/~gregs/dynamorio.html
-.. file = ivme03.pdf
+.. [S03] Gregory Sullivan et. al., "Dynamic Native Optimization of Native
+Interpreters". IVME 03. 2003. http://www.ai.mit.edu/~gregs/dynamorio.html
+.. file = ivme03.pdf
.. [LHJ95] Sheng Liang, Paul Hudak and Mark Jones. "Monad Transformers
and Modular Interpreters". 22nd ACM Symposium on Principles of Programming
@@ -224,25 +222,25 @@
http://java.sun.com/people/sl/papers/popl95.ps.gz
.. file = popl95.ps.gz
-.. [H98] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98. 1998.
- http://haskell.org/frp/dsl.ps
+.. [H98] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98.
+1998. http://haskell.org/frp/dsl.ps
.. file = dsl.ps.gz
-.. [K97] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming". 1997.
- http://citeseer.nj.nec.com/kelsey97prescheme.html
+.. [K97] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming".
+1997. http://citeseer.nj.nec.com/kelsey97prescheme.html
.. file = kelsey97prescheme.pdf
-.. [IKM97] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay. "Back to the future: The story of Squeak, A practical Smalltalk written in itself." In Proceedings OOPSLA'97, pages 318--326, November 1997.
- ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html
-.. file = OOPSLA.Squeak.htm
-
-.. [A03] John Aycock, "A Brief History of Just-In-Time", ACM Computing Surveys 35, 2 (June 2003), pp. 97-113.
-.. file = jit-history.pdf
+.. [IKM97] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay.
+"Back to the future: The story of Squeak, A practical Smalltalk written in
+itself." In Proceedings OOPSLA'97, pages 318--326, November 1997.
+ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html.. file =
+OOPSLA.Squeak.htm.. [A03] John Aycock, "A Brief History of Just-In-Time", ACM
+Computing Surveys 35, 2 (June 2003), pp. 97-113... file = jit-history.pdf
.. [WAU99] Mario Wolczko, Ole Agesen, David Ungar,
- "Towards a Universal Implementation Substrate for Object-Oriented Languages", OOPSLA 99 workshop
- on Simplicity, Performance and Portability in Virtual Machine Design,
- OOPSLA '99, Denver, CO, Nov 2, 1999.
+ "Towards a Universal Implementation Substrate for Object-Oriented Languages",
+OOPSLA 99 workshop on Simplicity, Performance and Portability in Virtual
+Machine Design, OOPSLA '99, Denver, CO, Nov 2, 1999.
http://research.sun.com/research/kanban/oopsla-vm-wkshp.pdf
.. file = oopsla-vm-wkshp.pdf
@@ -263,13 +261,14 @@
.. file = hlzle91optimizing.ps.gz
.. [HU94] Urs Hölzle, David Ungar,
- "Reconciling Responsiveness with Performance in Pure Object-Oriented Languages",
- PLDI '94 and OOPSLA '94
- http://www.cs.ucsb.edu/oocsb/papers/toplas96.pdf/reconciling-responsiveness-with-performance.pdf
-.. file = reconciling-responsiveness-with-performance.pdf
-
+ "Reconciling Responsiveness with Performance in Pure Object-Oriented
+Languages", PLDI '94 and OOPSLA '94
+
+http://www.cs.ucsb.edu/oocsb/papers/toplas96.pdf/reconciling-responsiveness-with
+-performance.pdf.. file = reconciling-responsiveness-with-performance.pdf
.. [KLM97] Gregor Kiczales and John Lamping and
Anurag Menhdhekar and Chris Maeda and Cristina Lopes and Jean-Marc
Loingtier and John Irwin, "Aspect-Oriented Programming", ECOOP'97
- http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-ECOOP97/for-web.pdf
-.. file = kiczales97aspectoriented.pdf
+
+http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-ECOOP97/for-web
+.pdf.. file = kiczales97aspectoriented.pdf
\ No newline at end of file
More information about the Pypy-commit
mailing list