PyCon VM summit
By john.rose on Mar 25, 2009
There is a fork of CPython at Google called "Unladen Swallow" (I can't stop thinking of how Pythons eat; aghh). Its goal is to get 5x speedup in one year, by the application of google-osity to pythonic performance problems. BTW, like Ruby, new Python implementations are challenged by the need to either rewrite or cope with existing giant libraries written in C. This would be a huge problem for Java, as the JVM has all sorts of strong execution invariants that C code would break, were it not for the firewall of JNI.
JRuby (yes, Charlie and Tom were there) is able to punt some of its performance problems to the JVM's JIT, GC, and general multiprocessor support. Their challenge is reimplementing Ruby without a specification; this also is a characteristic problem of the new crop of languages. (I'm now even more grateful for the excellent early work on specs. in the Java ecosystem.) They are running a Ruby interpreter, which then JITs (after a short warmup) to JVM bytecodes, which (they hope) the JVM eventually JITs to machine code. Like Python (and Java) they need a foreign function interface which is fast and easy to use.
Meanwhile, Jython has very simple bytecode translation; hopefully both they and JRuby will make more use of invokedynamic by JavaOne.
PyPy continues to be a fascinating exercise in bootstrapping. Their toolchain generates, from a factored group of executable specifications, the whole Python interpreter and GC, which makes it easy (when it works) to fold in read/write barriers, security checks, trace JITs, and other exotica. They run fully stackless. (A number of people talked about stackless execution. Part of the attraction is easy support for generators and perhaps other coroutines; part of the attraction is an inverse repulsion from the C stack, which is hard to control.)
Rubinius is a reimplementation of
Python Ruby in the style of Smalltalk 80, including dead-simple bytecodes and those cute backtracking primitives. (ST80 primitives can fail on arguments they don't want to handle, causing the VM to run the associated bytecoded method.) It also is stackless. It has an "Immix" GC (regional, kind of like OpenJDK's G1). As with a number of these systems, a JIT seems imminent... though JITs always take longer.
There were other cool VMs, including Spider Monkey (trace-based from Mozilla), Parrot (continuation-based stackless), MagLev, and Factor. After the presentations, we hung around the room all day and talked ourselves until exhaustion, then went and ate and talked more. It was a memorable day!