From the translator: a couple of hours ago, Guido, in his twitter, mentioned the blog post of his colleague, one of the (former) developers of Unladen Swallow, in which he tells the sad story of Unladen Swallow’s vivid but short life on Google.

Original: Reid Kleckner - Unladen Swallow Retrospective

Unladen Swallow: Retrospective

')
I started writing this while I was at PyCon, but I’ve been fine-tuning the text ever since. Anyway, here. :)

As is already obvious, no one else seriously takes care of either Unladen Swallow directly or porting it to py3k. Why?

Loss of customer interest

The main reason is that Google hasn’t found enough potential users for Unladen Swallow. This is due to several reasons:

1. For the main volume of the Python-code in Google high performance is not required. Python is mainly used for tools and prototyping, while the main end-user applications are written in Java and C ++.
2. The same internal users, for whom performance was important, were embarrassed by the too complex deployment requirements of Unladen Swallow. For them, it was not just necessary that Unladen Swallow be a replacement for CPython — any new Python implementation would have to replace the existing one on a turnkey basis. We thought that, basing the source code on CPython, rather than starting development from absolute zero, we avoid this problem, because all the extensions to C and SWIG wrappers will continue to work as if nothing had happened. Nevertheless, even the transition from the previous version of CPython to Python 2.6 was too complicated.
3. Our potential users somehow found other ways to solve their performance problems, which turned out to be more convenient for them to deploy.

After my internship ended, I tried to make Unladen the theme of my MIT master's thesis, but my manager found that the results achieved at that time did not promise good prospects, and that the concepts I wanted to apply were no longer considered modern. Basic techniques (from translator: I mean techniques for generating optimized code based on tracking the process of performing non-optimized) feedback, and already implemented by Urs Hölzle for Smalltalk, and tracing techniques - by Andreas Gil (from comments: in fact, Andreas Gal) for java. Of course, this does not mean that no one else could invent new techniques, but at that time I had no fresh ideas.

Loss of self interest

Basically, all of the above was considered in the first quarter of 2010. We could still decide to work on Unladen in our free time, but that would be different.

First, working on a project alone is far from being so cool as with other people, especially if it is not obvious whether your creation will ever have users.

Secondly, one of the main reasons for our interest was that we thought that PyPy would never even try to support extensions in C or SWIG-wrapped code. We were quite surprised when we learned that the PyPy project started moving precisely in this direction. This has partially alleviated the need for a “plug-in” JIT for CPython. In addition, when the project was launched, PyPy did not yet support the 64-bit platform, but over time they added this support.

And, in the end, the comments in python-dev that we read did not encourage us. People assumed that if Unladen Swallow falls into py3k, then this code will be supported by Google, but these assumptions were already groundless. If code misses it would seem, it would mean that by default JIT would be turned off, and in a year, due to rare use and lack of support , it would have to be removed again. Very few developers were interested in the new JIT. We never kept the code, but we hoped that if we finished, we could inspire the developers of CPython to catch it.

So, taking into account all of the above reasons why none of us are engaged in Unladen anymore, what do we understand?

Conclusions about LLVM

First, we deeply studied the pros and cons of using LLVM to generate JIT code. Our initial decision to use LLVM was made due to the fact that none of us knew the x86 assembler deeply enough, but we also wanted to support both x86 and x86_64, and maybe even ARM. We considered the option to recycle psyco, but refused mainly because of the need for deep knowledge of x86.

Unfortunately, at the moment LLVM is too focused on use as a static optimizer and backend. Code generation and optimization of LLVM are good, but too “expensive” to use. The optimizations are too focused on working with intermediate code representation generated by static C-like languages. Most of the basic techniques for optimizing Python require a high-level representation of how the program worked on previous iterations, which was difficult with LLVM.

An example of how high-level code generation is used is optimization of work with the Python stack. LLVM is not able to optimize reading from the Python stack between calls to external functions (that is, the CPython environment, which means it never actually). To solve this problem, we finally had to write an analysis of aliases, and all this is a typical example of what you encounter if you do not create your own code generator.

In addition, other restrictions apply to LLVM. For example, LLVM does not seriously support back-patching (from the translator: apparently, dynamic code modification) , which PyPy uses for editing on the fly outputs from the validation branches of the working code. This is quite an important requirement with significant memory consumption, but I would argue with the latter, because according to the results of Steven Noonan’s work within the GSOC, the consumption can be reduced, especially considering that PyPy has a higher memory consumption.

In addition, I spent the summer creating an interface between LLVM JIT and gdb. It was not necessary, but the result was a useful tool. I don’t know what is being used to debug PyPy now, but we can take advantage of our experience and apply it to PyPy.

results

Personally, I, before starting work on this project, took a course on compilers and operating systems, but the experience I gained during my work brought me a huge amount of new skills. I am now quite well versed in gdb, rules it for myself and even debugged gdb with gdb. Now I know a lot more about x86, compiler optimization techniques, JIT features, and this is what I use in my master’s work.

I am also very proud of our macro benchmark collection of real Python applications, which is now actively used by the PyPy project: speed.pypy.org . Perhaps from all my performance-related Python activities, he turned out to be the most useful. Any change in performance is easy to see from changes in results before and after it appears.

We also brought some benefits to LLVM, thereby helping other LLVM-based JIT projects, such as Parrot and Rubinius. For example, I helped fix the 16-megabyte restriction on the code being analyzed by JIT. Again, now for the LLVM JIT there is an interface gdb. Jeff also spent a lot of time so that C-shny functions could be compiled directly into JIT-generated code, as well as editing memory leaks and adding a TypeBuilder pattern to build C-shny types in LLVM.

Therefore, no matter how much I wish there were more resources, and the project would survive, it all brought me great experience, we managed to bring some benefits to LLVM and create a very useful set of benchmarks.