[pypy-svn] r80373 - pypy/extradoc/talk/ustour2011
lac at codespeak.net
lac at codespeak.net
Mon Feb 21 02:37:18 CET 2011
Date: Mon Feb 21 02:37:16 2011
New Revision: 80373
canabalise the Stanford text. tighten text. Still one XXX left but I think
its nearly ready to ship, and about time too.
--- 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.
-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.
-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
+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
+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
* most Python benchmarks run much faster than with CPython or Psyco
- "10x speedup in the average case for a tight loop in python"
+* 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/ .
More information about the Pypy-commit