[pypy-commit] extradoc extradoc: cite some of our papers and don't mention .net/java too promoninently as targets

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4596:49e5490d5570
Date: 2012-08-15 14:59 +0200
http://bitbucket.org/pypy/extradoc/changeset/49e5490d5570/

Log:	cite some of our papers and don't mention .net/java too
	promoninently as targets

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -212,34 +212,42 @@
 The RPython language and the PyPy project were started in 2002 with the goal of
 creating a Python interpreter written in a high level language, allowing easy
 language experimentation and extension. PyPy is now a fully compatible
-alternative implementation of the Python language, that is on average about 5 times faster than the reference implementation. The
-implementation takes advantage of the language features provided by RPython
+alternative interpreter for the Python language.
+Using RPython's tracing JIT compiler it is on average about 5 times faster than
+CPython, the reference implementation.
+PyPy is an interpreter written in RPython and takes advantage of the language
+features provided by RPython
 such as the provided tracing just-in-time compiler described below.
 
 RPython, the language and the toolset originally developed to implement the
 Python interpreter have developed into a general environment for experimenting
 and developing fast and maintainable dynamic language implementations. There
-are, besides the Python interpreter, implementations of Prolog, Javascript, R,
-Smalltalk among other that are written in RPython at different levels of
-completeness.
+are, besides the Python interpreter, experimental implementations of
+Prolog~\cite{bolz_towards_2010}, Javascript, R,
+Smalltalk~\cite{bolz_towards_2010} among other that are written in RPython at
+different levels of completeness.
 
-RPython is constructed from two components:
+RPython can mean one of two things:
 \begin{itemize}
  \item the language itself
  \item the translation toolchain used to transform RPython programs to executable units
 \end{itemize}
 The RPython language
-is a statically typed object oriented high level language. The language provides
+is a statically typed object-oriented high level language. The language provides
 several features such as automatic memory management
 and just-in-time compilation. When writing an interpreter using RPython the
 programmer only has to write the interpreter for the language she is
 implementing.  The second RPython component, the translation toolchain, is used
-to transform the program to a low level representations suited to be compiled
-and run on one of the different supported target platforms/architectures such
-as C, .NET and Java. During the transformation process
+to transform the interpreter into a C program.\footnote{
+    RPython can also be used to translate programs to CLR and Java
+    bytecode~\cite{ancona_rpython:_2007}, but this feature is somewhat
+    experimental.
+}
+During the transformation process
 different low level aspects suited for the target environment are automatically
-added to the program such as (if needed) a garbage collector
-and based on hints provided by the author a just-in-time compiler.
+added to the program such as a garbage collector and a tracing JIT compiler.
+The process of inserting a tracing JIT is not fully automatic but is guided by
+hints from the interpreter author.
 
 \subsection{RPython's Tracing JIT Compilers}
 \label{sub:tracing}
diff --git a/talk/vmil2012/zotero.bib b/talk/vmil2012/zotero.bib
--- a/talk/vmil2012/zotero.bib
+++ b/talk/vmil2012/zotero.bib
@@ -41,6 +41,20 @@
 	pages = {19--28}
 },
 
+ at inproceedings{bolz_towards_2010,
+	address = {Hagenberg, Austria},
+	title = {Towards a Jitting {VM} for Prolog execution},
+	isbn = {978-1-4503-0132-9},
+	url = {http://portal.acm.org/citation.cfm?id=1836102},
+	doi = {10.1145/1836089.1836102},
+	abstract = {Most Prolog implementations are implemented in low-level languages such as C and are based on a variation of the {WAM} instruction set, which enhances their performance but makes them hard to write. In addition, many of the more dynamic features of Prolog (like assert), despite their popularity, are not well supported. We present a high-level continuation-based Prolog interpreter based on the {PyPy} project. The {PyPy} project makes it possible to easily and efficiently implement dynamic languages. It provides tools that automatically generate a just-in-time compiler for a given interpreter of the target language, by using partial evaluation techniques. The resulting Prolog implementation is surprisingly efficient: it clearly outperforms existing interpreters of Prolog in high-level languages such as Java. Moreover, on some benchmarks, our system outperforms state-of-the-art {WAM-based} Prolog implementations. Our paper aims to show that declarative languages such as Prolog can indeed benefit from having a just-in-time compiler and that {PyPy} can form the basis for implementing programming languages other than Python.},
+	booktitle = {{PPDP}},
+	publisher = {{ACM}},
+	author = {Bolz, Carl Friedrich and Leuschel, Michael and Schneider, David},
+	year = {2010},
+	keywords = {interpreters, jit, logic programming, partial evaluation}
+},
+
 @inproceedings{bebenita_spur:_2010,
 	address = {{Reno/Tahoe}, Nevada, {USA}},
 	title = {{SPUR:} a trace-based {JIT} compiler for {CIL}},
@@ -162,6 +176,21 @@
 	pages = {32&#8211;43}
 },
 
+ at inproceedings{ancona_rpython:_2007,
+	address = {Montreal, Quebec, Canada},
+	title = {{RPython:} a step towards reconciling dynamically and statically typed {OO} languages},
+	isbn = {978-1-59593-868-8},
+	shorttitle = {{RPython}},
+	url = {http://portal.acm.org/citation.cfm?id=1297091},
+	doi = {10.1145/1297081.1297091},
+	abstract = {Although the C-based interpreter of Python is reasonably fast, implementations on the {CLI} or the {JVM} platforms offers some advantages in terms of robustness and interoperability. Unfortunately, because the {CLI} and {JVM} are primarily designed to execute statically typed, object-oriented languages, most dynamic language implementations cannot use the native bytecodes for common operations like method calls and exception handling; as a result, they are not able to take full advantage of the power offered by the {CLI} and {JVM.}},
+	booktitle = {{DLS}},
+	publisher = {{ACM}},
+	author = {Ancona, Davide and Ancona, Massimo and Cuni, Antonio and Matsakis, Nicholas D.},
+	year = {2007},
+	keywords = {{JVM}, .net, Python}
+},
+
 @article{cytron_efficiently_1991,
 	title = {Efficiently Computing Static Single Assignment Form and the Control Dependence Graph},
 	volume = {13},
@@ -200,6 +229,21 @@
 	keywords = {toread}
 },
 
+ at incollection{bolz_back_2008,
+	title = {Back to the Future in One Week &#8212; Implementing a Smalltalk {VM} in {PyPy}},
+	url = {http://dx.doi.org/10.1007/978-3-540-89275-5_7},
+	abstract = {We report on our experiences with the Spy project, including implementation details and benchmark results. Spy is a re-implementation of the Squeak (i.e. Smalltalk-80) {VM} using the {PyPy} toolchain. The {PyPy} project allows code written in {RPython}, a subset of Python, to be translated
+to a multitude of different backends and architectures. During the translation, many aspects of the implementation can be
+independently tuned, such as the garbage collection algorithm or threading implementation. In this way, a whole host of interpreters
+can be derived from one abstract interpreter definition. Spy aims to bring these benefits to Squeak, allowing for greater portability and, eventually, improved performance. The current
+Spy codebase is able to run a small set of benchmarks that demonstrate performance superior to many similar Smalltalk {VMs}, but
+which still run slower than in Squeak itself. Spy was built from scratch over the course of a week during a joint Squeak-{PyPy} Sprint in Bern last autumn.},
+	booktitle = {Self-Sustaining Systems},
+	author = {Bolz, Carl Friedrich and Kuhn, Adrian and Lienhard, Adrian and Matsakis, Nicholas and Nierstrasz, Oscar and Renggli, Lukas and Rigo, Armin and Verwaest, Toon},
+	year = {2008},
+	pages = {123--139}
+},
+
 @article{holzle_third-generation_1994,
 	title = {A third-generation {SELF} implementation: reconciling responsiveness with performance},
 	volume = {29},