[pypy-svn] rev 1651 - in pypy/trunk/doc: . funding
arigo at codespeak.net
arigo at codespeak.net
Thu Oct 9 19:00:36 CEST 2003
Author: arigo
Date: Thu Oct 9 19:00:35 2003
New Revision: 1651
Added:
pypy/trunk/doc/psycoguide.ps.gz (contents, props changed)
Modified:
pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
Fixed references, added a Psyco "paper"
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 19:00:35 2003
@@ -20,16 +20,6 @@
:DELETE:END
-FIXME_ARMIN: shorten introduction to fit in 3 pages
-then refactor to fit with following plan:
-
-B.1.1 Problem to be solved
-
-B.1.2 Quantified specific objective
-
-B.1.3 Current State of The Art
-
-B.1.4 Beyond State of The Art
Scientific and technological objectives of the project & state of the art
===============================================================================
@@ -65,7 +55,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. [1]_
+flexibility. [S03]_
Subsequently, application developers are often left with bad choices not
only for productivity versus performance, but they have to work around
@@ -125,7 +115,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. [1]_
+flexibility. [S03]_
Taylorability is armed, e.g. subsetting and adaptation for small
memory footprint and small devices, while today's applications are to
@@ -177,7 +167,7 @@
Current State of The Art
------------------------------
-Haskell monadic modular interpreters [2]_ [3]_ are a
+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
@@ -195,8 +185,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) [4]_ and the
-Smalltalk (Squeak) [5]_ languages. Obtaining in this
+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
the gained flexibility much further, separating concerns between the
@@ -204,8 +194,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 [6]_ . But actually writing a JIT for
-a given language is generally a major task [7]_ .
+history is given in [A03]_ . But actually writing a JIT for
+a given language is generally a major task [WAU99]_ .
Different techniques to ease this path have been recently explored;
let us cite:
@@ -216,7 +206,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 [7]_ . As pointed out in
+ 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
@@ -228,27 +218,17 @@
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
- [1]_ . While this offers a highly competitive gain/effort
+ [S03]_ . 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 [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 [10]_
-[11]_ to deal more
-effectively with (highly) polymorphic call-sites.
-
+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. But this should not inherently be the
-case.
+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]_.
+
Beyond State of The Art
-----------------------------
@@ -258,12 +238,12 @@
data structures (frame stack, bytecode objects...); each individual
operation on objects is dispatched to the object space.
-Differently from cited related to work, we don't expect to encode a
+Unlike the related work previously cited, we don't expect to encode a
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,
-threading model etc at translation time.
+using the VHLL and -- most importantly -- the indirectness of translation,
+in 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
@@ -272,17 +252,19 @@
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 [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
+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
-translator which is also a weaver is expressed in full Python. For
-describing aspects and at system definition time we will be able to
-use the full dynamism of Python.
+translator is a weaver. For describing aspects and at system
+definition time we will be able to use the full dynamism of Python.
For debugging and comprehensibility we expect the core interpreter and
-Object Spaces to be runnable as a normal Python program on a Python
-interpreter.
+Object Spaces to be runnable as a normal Python program on the
+reference CPython interpreter.
+
+The translator itself will be innovative in that it XXX WRITING
+WRITING WRITING
FIXME_ARMIN
@@ -347,12 +329,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 [2]_ [3]_ are often underestimated by the community of language
+flexibility [LHJ95]_ [H98]_ 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. [1]_
+impairing the flexibility. [S03]_
The Flexibility Goal
@@ -439,8 +421,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 [4]_
-and Squeak [5]_ language, but we have an original approach
+approach has already been taken, e.g. for the Scheme [K97]_
+and Squeak [IKM97]_ 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
@@ -477,7 +459,7 @@
-------------
JIT compilers have been reasonably well studied; an account of their
-history is given in [6]_ . But actually writing a JIT for
+history is given in [A03]_ . 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:
@@ -488,20 +470,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 [7]_ .
+ 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 araises, we
are left with the hard problem of refactoring an efficient JIT-based
virtual machine.
- XXX state-of-the-art in Self: [10]_
- [11]_ .
+ XXX state-of-the-art in Self: [HCU91]_
+ [HU94]_ .
* 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 [1]_ . While this offers a
+ 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.
@@ -515,8 +497,8 @@
high-level Python source of PyPy.
This will be accomplished by integrating the technology developed in
-Psyco [8]_ , a prototype JIT for the Python programming language.
-XXX [9]_
+Psyco [R03]_ , a prototype JIT for the Python programming language.
+XXX [APJ03]_
It is
more precisely a specializing JIT compiler based on abstract
interpretation.
@@ -606,47 +588,47 @@
:DELETE:END
References:
-.. [1] Gregory Sullivan et. al., "Dynamic Native Optimization of Native Interpreters". IVME 03. 2003.
+.. [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
-.. [2] Sheng Liang, Paul Hudak and Mark Jones. "Monad Transformers
+.. [LHJ95] 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
-.. [3] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98. 1998.
+.. [H98] Paul Hudak. "Modular Domain Specific Languages and Tools". ICSR 98. 1998.
http://haskell.org/frp/dsl.ps
.. file = dsl.ps.gz
-.. [4] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming". 1997.
+.. [K97] Richard Kelsey, "Pre-Scheme: A Scheme Dialect for Systems Programming". 1997.
http://citeseer.nj.nec.com/kelsey97prescheme.html
.. file = kelsey97prescheme.pdf
-.. [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.
+.. [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
-.. [6] John Aycock, "A Brief History of Just-In-Time", ACM Computing Surveys 35, 2 (June 2003), pp. 97-113.
+.. [A03] John Aycock, "A Brief History of Just-In-Time", ACM Computing Surveys 35, 2 (June 2003), pp. 97-113.
.. file = jit-history.pdf
-.. [7] Mario Wolczko, Ole Agesen, David Ungar,
+.. [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.
http://research.sun.com/research/kanban/oopsla-vm-wkshp.pdf
.. file = oopsla-vm-wkshp.pdf
-.. [8] Armin Rigo, http://psyco.sourceforge.net
-.. file = xxx?
+.. [R03] Armin Rigo, http://psyco.sourceforge.net
+.. file = psycoguide.ps.gz
-.. [9] John Aycock and David Pereira and Georges Jodoin,
+.. [APJ03] 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,
+.. [HCU91] 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,
@@ -654,13 +636,13 @@
http://self.sunlabs.com/papers/ecoop91.ps.Z
.. file = hlzle91optimizing.ps.gz
-.. [11] Urs Hölzle, David Ungar,
+.. [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
-.. [12] Gregor Kiczales and John Lamping and
+.. [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
Added: pypy/trunk/doc/psycoguide.ps.gz
==============================================================================
Binary file. No diff available.
More information about the Pypy-commit
mailing list