[pypy-svn] r45513 - pypy/extradoc/talk/dyla2007
cfbolz at codespeak.net
cfbolz at codespeak.net
Mon Aug 6 12:04:19 CEST 2007
Author: cfbolz
Date: Mon Aug 6 12:04:18 2007
New Revision: 45513
Added:
pypy/extradoc/talk/dyla2007/talk.pdf (contents, props changed)
Modified:
pypy/extradoc/talk/dyla2007/talk.tex
Log:
version of the talk as given at ECOOP
Added: pypy/extradoc/talk/dyla2007/talk.pdf
==============================================================================
Binary file. No diff available.
Modified: pypy/extradoc/talk/dyla2007/talk.tex
==============================================================================
--- pypy/extradoc/talk/dyla2007/talk.tex (original)
+++ pypy/extradoc/talk/dyla2007/talk.tex Mon Aug 6 12:04:18 2007
@@ -25,10 +25,10 @@
Heinrich-Heine-Universität Düsseldorf
}
-\date{3rd Workshop on Dynamic Languages and Applications, July 31 2007}
+\date{3rd Workshop on Dynamic Languages and Applications, July 31st 2007}
-\pgfdeclareimage[height=0.5cm]{pypy-logo}{image/py-web.png}
-\logo{\pgfuseimage{pypy-logo}}
+%\pgfdeclareimage[height=0.5cm]{pypy-logo}{image/py-web.png}
+%\logo{\pgfuseimage{pypy-logo}}
@@ -74,7 +74,7 @@
\end{itemize}
\pause
\begin{block}{
- Our point}
+ Our points}
\begin{itemize}
\item
Do not write virtual machines ``by hand''
@@ -88,9 +88,9 @@
\begin{frame}
- \frametitle{Common Approaches to VM construction}
+ \frametitle{Common Approaches to Language Implementation}
\begin{block}{
- Using C directly (or C disguised as another language)}
+ Using C/C++ (potentially disguised as another language)}
\begin{itemize}
\item
CPython
@@ -99,9 +99,10 @@
\item
Spidermonkey (Mozilla's JavaScript VM)
\item
- but also: Squeak, Scheme48
+ but also: Scheme48, Squeak
\end{itemize}
\end{block}
+ \pause
\begin{block}{
Building on top of a general-purpose OO VM}
\begin{itemize}
@@ -109,6 +110,8 @@
Jython, IronPython
\item
JRuby, IronRuby
+ \item
+ various Prolog, Lisp, even Smalltalk implementations
\end{itemize}
\end{block}
\end{frame}
@@ -120,9 +123,9 @@
\item
flexibility, maintainability
\item
- simplicity of the VM
+ simplicity
\item
- performance (needs dynamic compilation techniques)
+ performance
\end{itemize}
\pause
\begin{block}{
@@ -141,32 +144,11 @@
\end{frame}
\begin{frame}
- \frametitle{Compilers are a bad encoding of Semantics}
- \begin{itemize}
- \item to reach good performance levels, dynamic compilation is often needed
- \item a dynamic compiler needs to encode language semantics
- \item this encoding is often obscure and hard to change
- \end{itemize}
- \pause
- \begin{block}{
- Python Case}
- \begin{itemize}
- \item
- Psyco is a dynamic compiler for Python
- \item
- synchronizing with CPython's rapid development is a lot of effort
- \item
- many of CPython's new features not supported well
- \end{itemize}
- \end{block}
-\end{frame}
-
-\begin{frame}
\frametitle{Fixing of Early Design Decisions}
\begin{itemize}
\item when starting a VM in C, many design decisions need to be made upfront
\item examples: memory management technique, threading model
- \item the decision is manifested throughout the VM source
+ \item such decisions are manifested throughout the VM source
\item very hard to change later
\end{itemize}
\pause
@@ -183,31 +165,28 @@
\end{frame}
\begin{frame}
- \frametitle{Implementation Proliferation}
+ \frametitle{Compilers are a bad encoding of Semantics}
\begin{itemize}
- \item
- restrictions of the original implementation lead to re-implementations,
- forks
- \item
- all implementations need to be synchronized with language evolution
- \item
- lots of duplicate effort
+ \item to reach good performance levels, dynamic compilation is often needed
+ \item a compiler (obviously) needs to encode language semantics
+ \item this encoding is often obscure and hard to change
\end{itemize}
\pause
\begin{block}{
Python Case}
\begin{itemize}
\item
- several serious implementations: CPython, Stackless, Psyco, Jython,
- IronPython, PyPy
+ Psyco is a dynamic compiler for Python
+ \item
+ synchronizing with CPython's rapid development is a lot of effort
\item
- the implementations have various grades of compliance
+ many of CPython's new features not supported well
\end{itemize}
\end{block}
\end{frame}
\begin{frame}
- \frametitle{Implementing Languages on Top of General-Purpose OO VMs}
+ \frametitle{Implementing Languages on Top of OO VMs}
\begin{itemize}
\item
users wish to have easy interoperation with the general-purpose OO VMs used
@@ -215,9 +194,9 @@
\item
therefore re-implementations of the language on the OO VMs are started
\item
- even more implementation proliferation
+ more implementations!
\item
- implementing on top of an OO VM has its own set of problems
+ implementing on top of an OO VM has its own set of benefits of problems
\end{itemize}
\pause
\begin{block}{
@@ -243,8 +222,6 @@
the VM supplies a GC and mostly a JIT
\item
better interoperability than what the C level provides
- \item
- some proponents believe that eventually one single VM should be enough
\end{itemize}
\pause
\begin{block}{
@@ -253,7 +230,7 @@
\item
both Jython and IronPython integrate well with their host OO VM
\item
- XXX what else?
+ Jython has free threading
\end{itemize}
\end{block}
\end{frame}
@@ -262,18 +239,12 @@
\frametitle{The problems of OO VMs}
\begin{itemize}
\item
- some of the benefits of OO VMs don't work out in practice
- \item
most immediate problem: it can be hard to map
- concepts of the dynamic lang to
+ concepts of the dynamic language to
the host OO VM
\item
performance is often not improved, and can be very bad, because of the
semantic mismatch between the dynamic language and the host VM
- \item
- poor interoperability with everything outside the OO VM
- \item
- in practice, one OO VM is not enough
\end{itemize}
\pause
\begin{block}{
@@ -282,16 +253,40 @@
\item
Jython about 5 times slower than CPython
\item
- IronPython is about as fast as CPython (but some introspection features
- missing)
+ IronPython is about as fast as CPython (but some stack introspection
+ features missing)
\item
- XXX something about semantic mismatch?
+ Python has very different semantics for method calls than Java
\end{itemize}
\end{block}
\end{frame}
\begin{frame}
+ \frametitle{Implementation Proliferation}
+ \begin{itemize}
+ \item
+ restrictions of the original implementation lead to re-implementations,
+ forks
+ \item
+ all implementations need to be synchronized with language evolution
+ \item
+ lots of duplicate effort, compatibility problems
+ \end{itemize}
+ \pause
+ \begin{block}{
+ Python Case}
+ \begin{itemize}
+ \item
+ several serious implementations: CPython, Stackless, Psyco, Jython,
+ IronPython, PyPy
+ \item
+ various incompatibilities
+ \end{itemize}
+ \end{block}
+\end{frame}
+
+\begin{frame}
\frametitle{PyPy's Approach to VM Construction}
\emph{Goal: achieve flexibility, simplicity and performance together}
@@ -303,8 +298,8 @@
\item
high-level description: an interpreter written in a high-level language
\item
- ... which we translate (i.e.\ compile) to VMs running on top of various
- targets, like C/Posix, CLR, JVM
+ ... which we translate (i.e.\ compile) to a VM running in various target
+ environments, like C/Posix, CLR, JVM
\end{itemize}
\end{frame}
@@ -324,7 +319,7 @@
\item
subset chosen in such a way that type-inference can be performed
\item
- still a high-level language (unlike SLang or Prescheme)
+ still a high-level language (unlike SLang or PreScheme)
\item
...really a subset, can't give a small example of code that
doesn't just look like Python :-)
@@ -336,8 +331,6 @@
\frametitle{Auto-generating VMs}
\begin{itemize}
\item
- high-level source: early design decisions not necessary
- \item
we need a custom \emph{translation toolchain} to compile the interpreter
to a full VM
\item
@@ -369,13 +362,14 @@
\item
dynamic languages can be implemented in a high level language
\item
- separation of concerns from low-level details
+ separation of language semantics from low-level details
\item
- a potential single-source-fits-all interpreter --
- less duplication of efforts
- \item
- runs everywhere with the same semantics --
- no outdated implementations, no ties to any standard platform
+ a single-source-fits-all interpreter
+ \begin{itemize}
+ \item runs everywhere with the same semantics
+ \item no outdated implementations, no ties to any standard platform
+ \item less duplication of efforts
+ \end{itemize}
\end{itemize}
\pause
\begin{block}{PyPy}
@@ -423,13 +417,12 @@
JIT compiler generator}
\begin{itemize}
\item
- almost orthogonal from the interpreter source - applicable to many
+ almost orthogonal from the interpreter source – applicable to many
languages, follows language evolution ``for free''
\item
- based on Partial Evaluation
+ based on Partial Evaluation techniques
\item
- benefits from a high-level interpreter and a tweakable translation
- toolchain
+ benefits from a high-level interpreter
\item
generating a dynamic compiler is easier than generating a static one!
\end{itemize}
@@ -437,7 +430,7 @@
\end{frame}
\begin{frame}
- \frametitle{Open Issues / Drawbacks / Further Work}
+ \frametitle{Drawbacks / Open Issues / Further Work}
\begin{itemize}
\item
writing the translation toolchain in the first place takes lots of effort
@@ -446,10 +439,7 @@
writing a good GC is still necessary. But: maybe we can reuse existing good
GCs (e.g.\ from the Jikes RVM)?
\item
- conceptually simple approach but many abstraction layers
- \item
dynamic compiler generation seems to work, but needs more efforts.
- Also: can we layer it on top of the JIT of a general purpose OO VM?
\end{itemize}
\end{frame}
@@ -457,22 +447,20 @@
\frametitle{Conclusion / Meta-Points}
\begin{itemize}
\item
+ VMs shouldn't be written by hand
+ \item
high-level languages are suitable to implement dynamic languages
\item
doing so has many benefits
\item
- VMs shouldn't be written by hand
- \item
PyPy's concrete approach is not so important
\item
- diversity is good
- \item
let's write more meta-programming toolchains!
\end{itemize}
\end{frame}
\begin{frame}
- \frametitle{Links}
+ \frametitle{Questions?}
\begin{block}{
PyPy}
\bigskip
More information about the Pypy-commit
mailing list