[pypy-svn] rev 1649 - pypy/trunk/doc/funding
pedronis at codespeak.net
pedronis at codespeak.net
Thu Oct 9 17:50:18 CEST 2003
Author: pedronis
Date: Thu Oct 9 17:50:17 2003
New Revision: 1649
Modified:
pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
converted references to use numbers
added ReST comments of the form
.. file = <file>
to still keep track of the corresponding files under svn
added para about Integr/Config tools.
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 17:50:17 2003
@@ -65,7 +65,7 @@
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.[ivme03.pdf]
+flexibility. [1]_
Subsequently, application developers are often left with bad choices not
only for productivity versus performance, but they have to work around
@@ -125,7 +125,7 @@
expense of other aspects (simplicity, flexibility again), possibly
culminating with the introduction of a native JIT, adding a
significant amount of code and complexity and further impairing the
-flexibility.[ivme03.pdf]
+flexibility. [1]_
Taylorability is armed, e.g. subsetting and adaptation for small
memory footprint and small devices, while today's applications are to
@@ -177,7 +177,7 @@
Current State of The Art
------------------------------
-Haskell monadic modular interpreters [popl95.ps.gz]_ [dsl.ps.gz]_ are a
+Haskell monadic modular interpreters [2]_ [3]_ 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
@@ -195,8 +195,8 @@
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
+taken, e.g. for the Scheme (Scheme 48) [4]_ and the
+Smalltalk (Squeak) [5]_ 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
@@ -204,8 +204,8 @@
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]_ .
+history is given in [6]_ . But actually writing a JIT for
+a given language is generally a major task [7]_ .
Different techniques to ease this path have been recently explored;
let us cite:
@@ -216,7 +216,7 @@
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
+ Self virtual machine in [7]_ . 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
@@ -228,20 +228,22 @@
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
+ [1]_ . 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
+interpreter. Psyco [8]_ XXX [9]_ is
an extension to it implementing a prototype JIT.
+FIXME_ARMIN
+
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.ps.gz]_
-[reconciling-responsiveness-with-performance.pdf]_ to deal more
+techniques as developed for Self [10]_
+[11]_ to deal more
effectively with (highly) polymorphic call-sites.
In its current incarnation it is also a delicate hand-crafted piece
@@ -260,8 +262,8 @@
fixed single interpreter in all its details in a subset of our VHLL
(Python). We plan to exploit the flexibility and abstraction gained by
the using of the VHLL subset and the indirectness of translation, in
-order to weave aspect such as memory management, object layout etc at
-translation time.
+order to weave aspect such as memory management, object layout,
+threading model etc at translation time.
In general we will explore for each feature and extension how to best
implement it by separating concerns between OO-customized Object
@@ -270,7 +272,7 @@
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 [kiczales97aspectoriented.pdf]_, although they have not been
+AOP ideas in [12]_, although they have not been
used on the interpreter for a large practical language. Our subset of
Python in which to express the core interpreter and Object Spaces is
the component language in the terminology of the paper, while the
@@ -282,6 +284,8 @@
Object Spaces to be runnable as a normal Python program on a Python
interpreter.
+FIXME_ARMIN
+
XXX something about what is innovative in the translator itself?
XXX currently the "The Translator section"
@@ -310,6 +314,11 @@
to) the normal C expressions that would be the direct translation.
XXX /edit
+Finally we expect to develop automatic tools that should allow
+language users to compose and construct interpreters in a streamlined
+way from choices about aspects and predefined or user-supplied
+extensions.
+
:DELETE:BEGIN
Introduction
@@ -338,12 +347,12 @@
difficult to factor into relatively independent components, which makes
structural changes to a large interpreter cumbersome. While the
efficiency costs are well-known, the costs inherent to the lack
-flexibility [popl95.ps.gz]_ [dsl.ps.gz]_ are often underestimated by the community of language
+flexibility [2]_ [3]_ are often underestimated by the community of language
users. In practice, what often occurs for newly popular languages is
that the user base creates pressure about the efficiency issue and
motivates a group of developers to write a native Just In Time (JIT)
compiler, adding a significant amount of code and complexity and further
-impairing the flexibility.[ivme03.pdf]_
+impairing the flexibility. [1]_
The Flexibility Goal
@@ -430,8 +439,8 @@
the additional constraint that core parts should be written in a more
static subset of the language, a restriction that opens the door to
static analysis and translation to a low-level language like C. This
-approach has already been taken, e.g. for the Scheme [kelsey97prescheme.pdf]_
-and Squeak [OOPSLA.Squeak.html]_ language, but we have an original approach
+approach has already been taken, e.g. for the Scheme [4]_
+and Squeak [5]_ language, but we have an original approach
to the translation process that we will describe later.
The net result will be an interpreter whose performance is comparable to
@@ -468,7 +477,7 @@
-------------
JIT compilers have been reasonably well studied; an account of their
-history is given in [jit-history.pdf]_ . But actually writing a JIT for
+history is given in [6]_ . But actually writing a JIT for
a given language is generally a major task. Different techniques to ease
this path have been recently explored; let us cite:
@@ -479,20 +488,20 @@
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]_ .
+ in [7]_ .
As pointed out in that paper, some source language features may not match
any of the target virtual machine features. When this issue araises, we
are left with the hard problem of refactoring an efficient JIT-based
virtual machine.
- XXX state-of-the-art in Self: [hlzle91optimizing.ps.gz]_
- [reconciling-responsiveness-with-performance.pdf]_ .
+ XXX state-of-the-art in Self: [10]_
+ [11]_ .
* 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
+ processor-time interpretative overhead [1]_ . While this offers a
highly competitive gain/effort ratio, performance does not reach the
levels of a hand-crafted JIT.
@@ -506,8 +515,8 @@
high-level Python source of PyPy.
This will be accomplished by integrating the technology developed in
-Psyco [psyco]_ , a prototype JIT for the Python programming language.
-XXX [ucpy-reverse-engineering-python.pdf]_
+Psyco [8]_ , a prototype JIT for the Python programming language.
+XXX [9]_
It is
more precisely a specializing JIT compiler based on abstract
interpretation.
@@ -597,50 +606,62 @@
:DELETE:END
References:
+.. [1] Gregory Sullivan et. al., "Dynamic Native Optimization of Native Interpreters". IVME 03. 2003.
+ http://www.ai.mit.edu/~gregs/dynamorio.html
+.. file = ivme03.pdf
-.. [popl95.ps.gz] Sheng Liang, Paul Hudak and Mark Jones. "Monad Transformers
+.. [2] Sheng Liang, Paul Hudak and Mark Jones. "Monad Transformers
and Modular Interpreters". 22nd ACM Symposium on Principles of Programming
Languages (POPL'95). January 1995.
http://java.sun.com/people/sl/papers/popl95.ps.gz
+.. file = popl95.ps.gz
-.. [dsl.ps.gz] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98. 1998.
+.. [3] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98. 1998.
http://haskell.org/frp/dsl.ps
+.. file = dsl.ps.gz
-.. [ivme03.pdf] Gregory Sullivan et. al., "Dynamic Native Optimization of Native Interpreters". IVME 03. 2003.
- http://www.ai.mit.edu/~gregs/dynamorio.html
-
-.. [kelsey97prescheme.pdf] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming". 1997.
+.. [4] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming". 1997.
http://citeseer.nj.nec.com/kelsey97prescheme.html
+.. file = kelsey97prescheme.pdf
-.. [OOPSLA.Squeak.html] 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.
+.. [5] 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
-.. [jit-history.pdf] John Aycock, "A Brief History of Just-In-Time", ACM Computing Surveys 35, 2 (June 2003), pp. 97-113.
+.. [6] John Aycock, "A Brief History of Just-In-Time", ACM Computing Surveys 35, 2 (June 2003), pp. 97-113.
+.. file = jit-history.pdf
-.. [oopsla-vm-wkshp.pdf] Mario Wolczko, Ole Agesen, David Ungar, "Towards a Universal Implementation Substrate for Object-Oriented Languages", OOPSLA 99 workshop
+.. [7] 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.
http://research.sun.com/research/kanban/oopsla-vm-wkshp.pdf
+.. file = oopsla-vm-wkshp.pdf
+
+.. [8] Armin Rigo, http://psyco.sourceforge.net
+.. file = xxx?
-.. [hlzle91optimizing.ps.gz] Urs Hölzle, Craig Chambers, and David Ungar,
+.. [9] John Aycock and David Pereira and Georges Jodoin,
+ "UCPy: Reverse-Engineering Python", PyCon DC 2003, 9pp.
+ http://pages.cpsc.ucalgary.ca/~aycock/papers/ucpy.pdf
+.. file = ucpy-reverse-engineering-python.pdf
+
+.. [10] Urs Hölzle, Craig Chambers, and David Ungar,
"Optimizing Dynamically-Typed Object-Oriented Languages with Polymorphic
Inline Caches", ECOOP'91 Conference Proceedings, Geneva, 1991. Published
as Springer Verlag Lecture Notes in Computer Science 512, Springer Verlag,
Berlin, 1991.
http://self.sunlabs.com/papers/ecoop91.ps.Z
+.. file = hlzle91optimizing.ps.gz
-.. [reconciling-responsiveness-with-performance.pdf] Urs Hölzle, David Ungar,
+.. [11] 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
-.. [psyco] Armin Rigo, http://psyco.sourceforge.net
-
-.. [ucpy-reverse-engineering-python.pdf] John Aycock and David Pereira and Georges Jodoin, "UCPy: Reverse-Engineering Python", PyCon DC 2003, 9pp.
- http://pages.cpsc.ucalgary.ca/~aycock/papers/ucpy.pdf
-
-.. [kiczales97aspectoriented.pdf] Gregor Kiczales and John Lamping and
+.. [12] 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
More information about the Pypy-commit
mailing list