[pypy-svn] extradoc extradoc: some notes about related work out of a discussion with samuele

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r3421:4f1077a55c4b
Date: 2011-03-26 23:52 +0100
http://bitbucket.org/pypy/extradoc/changeset/4f1077a55c4b/

Log:	some notes about related work out of a discussion with samuele

diff --git a/talk/icooolps2011/paper.tex b/talk/icooolps2011/paper.tex
--- a/talk/icooolps2011/paper.tex
+++ b/talk/icooolps2011/paper.tex
@@ -814,8 +814,31 @@
 
 \section{Related Work}
 
+partial evaluation \cite{futamura_partial_1999} \cite{jones_partial_1993}
+
+earlier examples of promotion \cite{carl_friedrich_bolz_towards_????}, \cite{armin_rigo_jit_2007}
+
+meta-tracers: SPUR \cite{bebenita_spur:_2010}
+tamarin/lua stuff \cite{yermolovich_optimization_2009}
+Dynamo \cite{sullivan_dynamic_2003}
+
+\cite{chambers_efficient_1989} maps
+\cite{hoelzle_optimizing_1994} Type feedback
+\cite{hoelzle_optimizing_1991} PICs
+find the web page of V8 about maps
+
+is there anything about versions? smalltalks tend to clear their method caches
+when new methods are added. self and java use dependency tracking and
+deoptimization. this is better what we have above, because we need runtime
+checks. mention out of line guard?
+
+jruby used versions at some point, jvm-l mailing list discusses them
+
 \cite{mario_wolczko_towards_1999}
 
+invokedynamic tries to give control to the language implementor about PICs and
+deoptimization
+
 \section{Conclusion and Next Steps}
 
 In this paper we presented two hints that can be used in the source code of an

diff --git a/talk/icooolps2011/paper.bib b/talk/icooolps2011/paper.bib
--- a/talk/icooolps2011/paper.bib
+++ b/talk/icooolps2011/paper.bib
@@ -206,6 +206,19 @@
 	pages = {53--64}
 },
 
+ at article{futamura_partial_1999,
+	title = {Partial Evaluation of Computation Process - An Approach to a {Compiler-Compiler}},
+	volume = {12},
+	url = {http://citeseer.ist.psu.edu/futamura99partial.html},
+	number = {4},
+	journal = {{Higher-Order} and Symbolic Computation},
+	author = {Yoshihiko Futamura},
+	year = {1999},
+	keywords = {Futamura},
+	pages = {381--391},
+	annote = {{{\textless}p{\textgreater}Classical} futamura paper, defines partial evaluation as follow:{\textless}/p{\textgreater}{\textless}p{\textgreater}\&nbsp;{\textless}/p{\textgreater}{\textless}p{\textgreater}a function f(c, r) to some output. partial evaluation is a function a such that{\textless}/p{\textgreater}{\textless}p{\textgreater}f(c`, r`) = a(f, c`)(r`){\textless}/p{\textgreater}{\textless}p{\textgreater}\&nbsp;{\textless}/p{\textgreater}{\textless}p{\textgreater}hints at futamura-projections. Describes a vague algorithm for actually doing partial evaluation. The algorithm contains some elements that are quite similar to merging.{\textless}/p{\textgreater}}
+},
+
 @book{jones_partial_1993,
 	title = {Partial evaluation and automatic program generation},
 	isbn = {0-13-020249-5},
@@ -400,6 +413,21 @@
 	pages = {15--26}
 },
 
+ at inproceedings{sullivan_dynamic_2003,
+	address = {San Diego, California},
+	title = {Dynamic native optimization of interpreters},
+	isbn = {1-58113-655-2},
+	url = {http://portal.acm.org/citation.cfm?id=858570.858576},
+	doi = {10.1145/858570.858576},
+	abstract = {For domain specific languages, "scripting languages", dynamic languages, and for virtual machine-based languages, the most straightforward implementation strategy is to write an interpreter. A simple interpreter consists of a loop that fetches the next bytecode, dispatches to the routine handling that bytecode, then loops. There are many ways to improve upon this simple mechanism, but as long as the execution of the program is driven by a representation of the program other than as a stream of native instructions, there will be some "interpretive {overhead".There} is a long history of approaches to removing interpretive overhead from programming language implementations. In practice, what often happens is that, once an interpreted language becomes popular, pressure builds to improve performance until eventually a project is undertaken to implement a native Just In Time {(JIT)} compiler for the language. Implementing a {JIT} is usually a large effort, affects a significant part of the existing language implementation, and adds a significant amount of code and complexity to the overall code {base.In} this paper, we present an innovative approach that dynamically removes much of the interpreted overhead from language implementations, with minimal instrumentation of the original interpreter. While it does not give the performance improvements of hand-crafted native compilers, our system provides an appealing point on the language implementation spectrum.},
+	booktitle = {Proceedings of the 2003 workshop on Interpreters, virtual machines and emulators},
+	publisher = {{ACM}},
+	author = {Gregory T. Sullivan and Derek L. Bruening and Iris Baron and Timothy Garnett and Saman Amarasinghe},
+	year = {2003},
+	pages = {50--57},
+	annote = {{{\textless}p{\textgreater}Describes} the application of Dynamo to interpreters. The unchanged dynamo does not fare too well on interpreters, since it traces one iteration of the bytecode loop, and the next iteration is likely to be very different. Matters are improved by adding hints to the interpreter that tell the tracer what the program counter of the interpreter is. Then the tracer only closes loops at the application {level.{\textless}/p{\textgreater}{\textless}p{\textgreater}\&nbsp;{\textless}/p{\textgreater}{\textless}p{\textgreater}Strong} restrictions due to the fact that things happen on the assembler level.{\textless}/p{\textgreater}}
+},
+
 @incollection{carl_friedrich_bolz_back_2008,
 	title = {Back to the Future in One Week {\textemdash} Implementing a Smalltalk {VM} in {PyPy}},
 	url = {http://dx.doi.org/10.1007/978-3-540-89275-5_7},