[pypy-svn] r80373 - pypy/extradoc/talk/ustour2011

[lac at codespeak.net]

Author: lac
Date: Mon Feb 21 02:37:16 2011
New Revision: 80373

Modified:
   pypy/extradoc/talk/ustour2011/dropbox.txt
Log:
canabalise the Stanford text.  tighten text.  Still one XXX left but I think
its nearly ready to ship, and about time too.


Modified: pypy/extradoc/talk/ustour2011/dropbox.txt
==============================================================================
--- pypy/extradoc/talk/ustour2011/dropbox.txt	(original)
+++ pypy/extradoc/talk/ustour2011/dropbox.txt	Mon Feb 21 02:37:16 2011
@@ -17,69 +17,73 @@
 has outperformed Psyco, while being much more general and robust.
 
 Abstract:
-The PyPy project has recently gathered a lot of attention for its
-progress in speeding up the Python language -- it is the fastest,
-most compatible and most stable 'alternative´ Python interpreter.  No
-longer merely a research curiosity, PyPy is now suitable for production
-use.  Since 2009, the PyPy project has received funding from the Eurostars 
-Eureka program, which targets small European firms which produce research.
-(See: http://www.eurostars-eureka.eu/)
-
-This talk will begin with an introduction to PyPy and then a more detailed
-discussion of what we have accomplished with the past two years' work in 
-the area of dynamic (Just-in-Time) interpreters.  We have had some very
-useful comments from Rian Hunter about areas of interest to dropbox, and
-we will finally discuss those bits which weren't already discussed.:
+PyPy is a complete Python implementation in Python, in the old
+tradition of Squeak and Scheme48 --- but there is more to PyPy
+than just this.
+
+During this talk I will describe what PyPy is: a mature,
+8 year old project of roughly 200K lines of code and 150K lines
+of tests, implementing the full Python language.  I will show our
+results: faster execution of most programs (by a factor between
+1.5x and 20x), and smaller total memory usage for large programs.
+
+I will then briefly focus on the architecture of PyPy.  On the one hand,
+we have written a straightforward interpreter for the Python
+language, using a (large) subset of Python called RPython.  On
+the other hand, we have a complex translation toolchain which is
+able to compile interpreters from RPython to efficient C code.
+(We also have experimental backends for producing JVM and .NET
+code.)
+
+There are two distinct benefits from keeping the interpreter and
+the translation toolchain separate.  On the one hand, we keep our
+interpreter simple, and we can easily write interpreters for
+other languages.  We have a complete Prolog interpreter and have
+at least played with versions for Smalltalk and Javascript.  On
+the other hand, the fact that our source interpreter does not
+contain any architectural choices makes for unprecedented
+flexibility.  Our toolchain "weaves" into the final executable
+various aspects including the object model, choice of garbage
+collection (GC), of execution model (regular vs. "Stackless"),
+choice of backend (C/JVM/.NET), and even the
+Just-in-Time Compiler (JIT).  There are great practical benefits
+to this.  For example, CPython's GC is stuck with using reference
+counting, while we offer a number of choices.
+
+We will then move to a more detailed discussion of what we have
+accomplished with the past two years' work in the area of dynamic
+(Just-in-Time) interpreters.  Lastly, we have had some very useful comments
+from Rian Hunter about subject matter that is of particular interest to 
+dropbox, and we will discuss these issues and any others brought up by
+members of the audience.
 
-* PyPy - the architecture XXX expand this
+Highlights include:
 
+* speed.pypy.org
 * most Python benchmarks run much faster than with CPython or Psyco
-  "10x speedup in the average case for a tight loop in python"
-  speed.pypy.org
+* tight loops run much faster, how much faster varies but XXX can we say on average  XXX faster?
 * the real-world PyPy compiler toolchain itself (200 KLocs) runs twice as fast
-* already supports 64bit and is in the process of supporting ARM
+* pypy already supports 64bit and is in the process of supporting ARM
 * full compatibility with  CPython (more than Jython/IronPython)
 * full (and JIT-ed) ctypes support to call C libraries from Python
 * supports Stackless Python (in-progress)
 * new "cpyext" layer which integrates existing CPython C extensions
 * an experimental super-fast JIT-compilation of calls to C++ libraries
-*A memory conservative JIT in steady state i.e. python right now  
-requires about 10MB of steady-state memory (all bytecodes / loaded  
-modules) not counting app usage. how much will that overhead increase  
-when using pypy? 
-     Maemo experiments.
-     Things we have done to shrink the memory usage.
-     But its huge now, anyway, because of the JIT.
-     What could be done to change this.
-     And do you really care about absolute size?  Or just that it can
-     scale and doesn't grow without bounds?
-
-* MIT license "so we can modify the runtime to generate obfuscated  
-pyc files" -- if your business really depends on obsfuscated code, and
-reverse engineering is a real worry for you, then we can do much better
-with pypy than what you are doing now.  (Anto cracked it already)
-
-*Compatibility with the major python executable packagers, py2exe,  
-py2app, and bfreeze (in that order)
-We're not going to embed a Cpython stub into an exe as py2exe does.
-We can produce executables with the python files embedded.  A PyPy packager.
-what it would look like.  What would be its advantages?
-(Actually we can produce a single exe that contains all
-necessary .py files already loaded; then there are no .py/.pyc files
-to distribute and obfuscate any more, and it's all in just one .exe.
-Such an .exe is maybe relatively large but compresses a lot.)
-
-*Future directions (what to do when Eurostars funding runs out)
-re: "The engineering resources to migrate won't require >1 month of work"
--- one option is to hire us to do the migration.
-
-
-*Any other aspect of interest to audience members.  We already got a nice 
-start on understanding your interests through a list of questons from
-Rian Hunter.  But if anybody else has ideas about what they would like
-us to speak about, (or if Rian gets some more ideas) could  they please
-send a note to lac at openend.se and we will make sure that we cover this
-in our presentation.
+* smaller total memory usage for large and long-running programs.
+* MIT license 
+  - with a digression on code-obsfuctation and pypy if there is
+    sufficient interest
+* pypy and binary packagers. Embedding pypy. One large .exe anyone?
+* Future directions.   Since 2009, the PyPy project has received funding 
+  from the Eurostars  Eureka program, which targets small European firms 
+  which produce research.  What should we do when the funding runs out?
+  One thing we would like is to be hired to migrate projects from CPython 
+  to PyPy.
+*Any other aspect of interest to audience members. 
+
+If there is something you are interested in which isn't mentioned in this
+abstract, please send a note to lac at openend.se and we will make sure that 
+we cover this in our presentation.
 
 The PyPy project has a blog which may be of interest.  You can read
 it at http://morepypy.blogspot.com/ .