[pypy-svn] r42019 - pypy/extradoc/talk/rupy2007

[fijal at codespeak.net]

Author: fijal
Date: Fri Apr 13 09:39:01 2007
New Revision: 42019

Added:
   pypy/extradoc/talk/rupy2007/fijal.txt
Modified:
   pypy/extradoc/talk/rupy2007/talk.txt
Log:
Update + my version


Added: pypy/extradoc/talk/rupy2007/fijal.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/rupy2007/fijal.txt	Fri Apr 13 09:39:01 2007
@@ -0,0 +1,228 @@
+XXX stealing from mwh
+
+What you' re in for in the next 45 mins
+=======================================
+
+* Quick intro and motivation
+* Introduction to features unique to PyPy,
+  including the JIT, with the odd demo
+* Quick overview of architecture and current statues
+* A little talk about what the future holds
+
+What is PyPy?
+==============
+* PyPy is:
+* An implementation of Python, and a very
+  flexible compiler framework (with some
+  features that are especially useful for
+  implementing interpreters)
+* An open source project (MIT license)
+* A STREP (''Specific Targeted REsearch
+  Project''), partially funded by the EU
+* A lot of fun!
+
+30 second status
+================
+
+* We can produce a binary that looks more and
+  more like CPython to the user
+* 1.5-3x slower, depending on details
+* Some modules supported -- socket, mmap, ...
+* Can now produce binary for CLR (i.e. .NET)
+* Can also produce more capable binaries --
+  with stackless-style coroutines, with logic
+  variables, ...
+
+Motivation
+===========
+* PyPy grew out of a desire to modify/extend
+  the implementation of Python, for example to:
+* increase performance (psyco-style JIT
+  compilation, better garbage collectors)
+* add expressiveness (stackless-style
+  coroutines, logic programming)
+* ease porting (to new platforms like the
+  JVM or CLI or to low memory situations)
+
+Lofty goals, but first...
+===========================
+* CPython is a fine implementation of Python
+  but:
+* it's written in C, which makes porting to,
+  for example, the CLI hard
+* while psyco and stackless exist, they are
+  very hard to maintain as Python evolves
+* some implementation decisions are very
+  hard to change (e.g. refcounting)
+
+Enter the PyPy platform
+========================
+
+XXX Copy picture
+
+Things that make PyPy unique
+===============================
+
+* The Just-In-Time compiler (and the way it
+  has been made)
+* Transparent Proxies
+* Runtime modifiable Grammar
+* Thunk object space
+* JavaScript (demos: b-n-b and rxconsole)
+* Logic programming
+
+Just-In-Time compiler
+========================
+
+* rather Just in time compiler generator
+* applicable to any possible interpreter
+  (writen in RPython)
+* scales to whole Python
+* XXX
+
+Multiple object implementations
+================================
+
+* XXX
+
+Transparent proxies
+====================
+
+* XXX
+
+Distribution
+================
+
+* XXX
+
+Stackless
+============
+
+* XXX
+
+Runtime modifiable grammar
+===========================
+
+* XXX
+
+How do you specify the Python language?
+========================================
+
+* The way we did it was to write an
+  interpreter for Python in RPython -- a subset
+  of Python that is amenable to analysis
+* This allowed us to write unit tests for our
+  specification/implementation that run on top
+  of CPython
+* Can also test entire specification/
+  implementation in same way
+
+Translation Aspects
+====================
+* Our Python implementation/specification is
+  very high level
+* One of our Big Goals is to produce our
+  customized Python implementations without
+  compromising on this point
+* We do this by weaving in so-called
+  'translation aspects' during the compilation
+  process
+
+1,000 meters view
+===============
+
+XXX We're on the continent
+XXX copy picture
+
+The Annotator
+=============
+
+* Works on control flow graphs of the source
+  program
+* Type annotation associates variables with
+  information about which values they can
+  take at run time
+* An unusual feature of PyPy's approach is that
+  the annotator works on live objects which
+  means it never sees initialization code, so
+  that can use exec and other dynamic tricks
+
+The Annotator
+==============
+
+* Annotation starts at a given entry point and
+  discovers as it proceeds which functions may
+  be called by the input program
+* Does not modify the graphs; end result is
+  essentially a big dictionary
+* Read ''Compiling dynamic language
+  implementations'' on the web site for more
+  than is on these slides
+
+The RTyper
+============
+
+* The RTyper takes as input an annotated
+  RPython program (e.g. our Python
+  implementation)
+* It reduces the abstraction level of the graphs
+  towards that of the target platform
+* This is where the magic of PyPy really starts
+  to get going :-)
+
+The RTyper
+===========
+
+* Can target a C-ish, pointer-using language or
+  an object-oriented language like Java or
+  Smalltalk with classes and instances
+* Resulting graphs are not completely low-
+  level: still assume automatic memory
+  management for example
+
+Reducing Abstraction
+======================
+
+* Many high level operations apply to different
+  types -- the most extreme example probably
+  being calling an object
+* For example, calling a function is RTyped to a
+  ''direct_call'' operation
+* But calling a class becomes a sequence of
+  operations including allocating memory for
+  the instance and calling any __init__
+  function
+
+Further Transforms
+===================
+
+* RTyping is followed by a sequence of further
+  transforms, depending on target platform and
+  options supplied:
+*  GC transformer -- inserts explicit memory
+   management operations
+*  Stackless transform -- inserts bookkeeping
+   and extra operations to allow use of
+   coroutines, tasklets etc
+*  Various optimizations -- malloc removal,
+   inlining, ...
+
+The Backend(s)
+===============
+
+* Maintained backends: C, LLVM, CLI/.NET,
+  JVM and JavaScript
+* All proceed in two phases:
+* Traverse the forest of rtyped graphs,
+  computing names for everything
+* Spit out the code
+
+XXX Write few words about future
+
+What future holds
+==================
+
+* A bit of a rest
+* More work on the JIT
+* Threads
+* Extenstion modules

Modified: pypy/extradoc/talk/rupy2007/talk.txt
==============================================================================
--- pypy/extradoc/talk/rupy2007/talk.txt	(original)
+++ pypy/extradoc/talk/rupy2007/talk.txt	Fri Apr 13 09:39:01 2007
@@ -29,10 +29,10 @@
   flexible compiler framework (with some
   features that are especially useful for
   implementing interpreters)
-*  An open source project (MIT license)
-*  A STREP (''Specific Targeted REsearch
-   Project''), partially funded by the EU
-*  A lot of fun!
+* An open source project (MIT license)
+* A STREP (''Specific Targeted REsearch
+  Project''), partially funded by the EU
+* A lot of fun!
 
 30 second status
 ================
@@ -51,11 +51,11 @@
 * PyPy grew out of a desire to modify/extend
   the implementation of Python, for example to:
 * increase performance (psyco-style JIT
-   compilation, better garbage collectors)
+  compilation, better garbage collectors)
 * add expressiveness (stackless-style
-   coroutines, logic programming)
+  coroutines, logic programming)
 * ease porting (to new platforms like the
-   JVM or CLI or to low memory situations)
+  JVM or CLI or to low memory situations)
 
 Lofty goals, but first...
 ===========================