Some thoughts on Python and Unladen Swallow

Between Twitter and the blogosphere, I have been hearing a lot about Unladen Swallow lately. For those who don't know, Unladen Swallow is an experimental branch of Python that aims at improving performance of the language. In their own words, Unladen Swallow is "An optimization branch of CPython, intended to be fully compatible and significantly faster."

I wanted to find out more and started reading their Project Plan page on Google Code. I think their goals are commendable, as you may see for yourself, and number 5 below explains why I added bold face the word branch above:

• Produce a version of Python at least 5x faster than CPython.
• Python application performance should be stable.
• Maintain source-level compatibility with CPython applications.
• Maintain source-level compatibility with CPython extension modules.
• We do not want to maintain a Python implementation forever; we view our work as a branch, not a fork.

This is all fine and dandy, and the list above has made the rounds on the blogs. But what does it all mean? What follows is my impressions of the most important points that the Unladen Swallow branch is addressing.

A New Virtual Machine

The goal is to eventually replace the Python 2.6.1 virtual machine with a just-in-time compiler built for the LLVM. The rest of the Python runtime would be left untouched. The key benefits of this approach are that is a register-based machine and those perform better than stack machines, which is what the current Python VM is implemented as.

The internals of the implementation will assume at the outset that the machine has multiple cores. For instance, very aggressive optimization of code is assigned to a secondary cores while compilation occurs on other cores. The garbage collector for Unladen Swallow will also be implemented to utilize multiple cores.

The Global Interpreter Lock

While Python has had threading for a while, it is not a true multi-threading implementation. This is because of the existence of the GIL. Dave Beazley has written about the GIL and how it works several times and you should read his "The Python GIL Visualized" article to find out more about why the GIL keeps Python from having a real multi-threaded runtime.

I bring up the GIL here because the folks working on Unladen Swallow plan on removing the GIL from Python, although they are not very optimistic about it. And even if they are not able to remove the GIL completely there may be other optimizations in the garbage collector reference counting mechanism that may yield some improvements in the threading area.

Anyway, these are the two major points I take away from the Unladen Swallow plan of record. These changes seem pretty big to me and a major risk of doing this kind of work is that your changes are rejected by the community. However, the Unladen Swallow team is sponsored by Google who also employs Guido, so I'm sure that those guys are talking amongst themselves.

Thanks for reading this, go read the project plan and let me know what you think.