[pypy-svn] r13982 - pypy/extradoc/talk

[hpk at codespeak.net]

Author: hpk
Date: Sun Jun 26 18:55:42 2005
New Revision: 13982

Added:
   pypy/extradoc/talk/pypy-ep2005-talk-prep.txt
Log:
draft EP 2005 talk preparation 



Added: pypy/extradoc/talk/pypy-ep2005-talk-prep.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/pypy-ep2005-talk-prep.txt	Sun Jun 26 18:55:42 2005
@@ -0,0 +1,109 @@
+
+http://www.python-in-business.org/ep2005/talk.chtml?talk=2238&track=687
+http://codespeak.net/~cfbolz/translation.pdf
+
+
+PyPy as a Compiler
+Carl Friedrich Bolz, Holger Krekel, Christian Tismer, Armin Rigo    60 minutes
+A status report on PyPy, the Python interpreter implemented in Python.
+
+1) introduction to the PyPy release 
+   Holger (10 minutes including thunk space example)
+     python implementation 
+
+2) type inference and specialization 
+    - flowgraph     \
+    - Annotation     |
+    - RTyper         |
+   15 minutes        | arigo
+                     |
+3) backends          |
+    - genc 5 min    /
+    - llvm 5 min               \
+                                |   cfbolz
+4) show demo/bpnn.py example    |
+   5 minutes                   /
+
+5) Conclusions & roadmap 2005/2006 
+   5 minutes 
+
+    the previous technqiues will be used internally to translate PyPy 
+    to low level languages.  In particular we aim for: 
+    (the primary point is NOT to systematically translate your own programs!)
+
+    - self-contained PyPy version before end 2005 
+
+    - stackless and psyco/JIT-compilation in 2006! 
+
+    - tool for building custom PyPy versions by end 2006
+
+
+
+The main part of the talk will be the second one, as it is where we are
+putting the most efforts at the moment: "how to turn an interpreter into
+a compiler".
+We will dig into:
+
+- what kind of programs we can statically compile;
+- the frontend infrastructure (control flow graph production, type
+  inference);
+- the C back-end, and the role of the "typer" component bridging the gap
+between high-level type annotations and the C data model;
+- the LLVM back-end (targetting a virtual machine with a different model
+and different trade-offs than plain C);
+- how this relates to our rather different long-term goal of making a
+  really
+fast PyPy interpreter.
+
+
+The PyPy project (http://codespeak.net/pypy) aims at producing a simple
+runtime system for the Python language, expressing the basic abstractions
+within the Python language itself. Simplicity and Flexibilty are the foremost
+goals.
+
+To reach our goal, we are currently working on a Python source analysis
+and compilation toolchain -- based on PyPy as well -- and a minimal low-level
+core that doesn't need CPython any more. The presentation will focus on
+these tools, which are able to perform automatic static type inference
+of "static enough" Python programs and then compile them to various lower-level
+languages (currently, we have experimental back-ends for C, LLVM, Python,
+Lisp, Pyrex and Java). This analysis works on fully standard Python sources
+(bytecodes, actually), and the distinguishing feature of the techniques
+we use -- "abstract interpretation" -- is to allow type inference to be
+performed for any language for which we have an interpreter. Moreover,
+it doesn't require explicit type annotations added by the user.
+
+To some extent, and although it is not our primary long-term goal, the
+tools we have developped could be used generally to check or improve the
+performance of any program. We will see in particular which "staticness"
+restrictions must be met for these tools to work, and look under the hood:
+
+
+* how we build control flow graphs;
+
+* how we perform type inference, and what "type inference" precisely
+* means
+in this context;
+
+* type inference is not the end of the story: good code must be
+* generated
+from the source and the inferred types.
+
+The presentation will focus on the latter point, explaining the two major
+code generators we have at the moment: the C and LLVM back-ends.
+
+The techniques relate to Psyco's, the just-in-time specializer for CPython.
+We will compare them, and also contrast the "internal" notion of type
+used as an implementation detail (as in PyPy and Psyco) with the other
+typical approach of explicit user-specified types. This point of view
+puts our current efforts in the more general context of our long-term goals,
+which are about dynamic optimizations rather than static compilation.
+
+Our approach is motivated by the desire of flexibility: it allows issues
+that normally require early design decisions to be postponed, and addressed
+later in possibly more than one way, without rewriting everything. Typical
+example: adding Stackless-style continuations in CPython required a whole-scale
+rewrite, but has only a "local" impact on PyPy. We will plead for a framework
+based on interpreters as a way to gain the most flexibility from programming
+languages -- and the best performances too, for very-high-level languages!
+