Kleckner: Unladen Swallow Retrospective [LWN.net]

Unladen Swallow developer Reid Kleckner has posted a look back at the project (which was working on an LLVM-accelerated Python implementation) and why it ended up so fiercely pining for the fjords. "Finally, the signals we were getting from python-dev were not good. There was an assumption that if Unladen Swallow were landed in py3k, Google would be there to maintain it, which was no longer the case. If the merge were to have gone through, it is likely that it would have been disabled by default and ripped out a year later after bitrot. Only a few developers seemed excited about the new JIT."

(Log in to post comments)

Kleckner: Unladen Swallow Retrospective

Posted Mar 27, 2011 19:13 UTC (Sun) by jetm (subscriber, #61129) [Link]

I think so. The last stable release Unladen Swallow at "October 20, 2009" and PyPy at "December 22, 2010". I hope PyPy follow a different way.

Kleckner: Unladen Swallow Retrospective

Posted Mar 28, 2011 10:41 UTC (Mon) by pboddie (subscriber, #50784) [Link]

PyPy is really coming into its own now, given that the JIT architecture seems to have settled down. I think there was a lot of skepticism from the direction of PyPy about whether Unladen Swallow could realistically deliver on a strategy which seemed to have a fair amount in common with Psyco (which is pretty much the forerunner of PyPy), and as the article mentions, when LLVM failed to provide the anticipated help in doing the tricky code generation parts, the effort required to tame LLVM in addition to doing all the other work probably weighed the project down a bit too much.

None of this indicates that you can't improve CPython's performance or build on CPython and get improved performance for, say, compiled (or "frozen", in Python-speak) programs. There are implementations which seem to have achieved these goals, albeit not at the order of magnitude level of performance improvement that one might like to see.

Personally, I think the remarks made in the Hacker News thread cross over with the observations about "turn-key" compatibility in the article and highlight a sticking point when it comes to improving Python's performance: lots of people won't even consider anything less than 100% compatibility with CPython with all the crazy hacks that it allows, making the optimisation work a lot harder than it otherwise might be. So people have traditionally turned their noses up at things which offer significant performance increases, and there's no debate about which parts of the language could usefully be jettisoned to provide such benefits more conveniently. If anything, people are still discussing yet more stuff to put in the language, not which stuff should arguably go away (or at least take a back seat).

Kleckner: Unladen Swallow Retrospective

Posted Mar 28, 2011 2:45 UTC (Mon) by flewellyn (subscriber, #5047) [Link]

That is REALLY fascinating. I didn't realize that Python's scoping rules caused such issues.

It's typical...

Posted Mar 28, 2011 6:07 UTC (Mon) by khim (subscriber, #9252) [Link]

This is usual result of "programming for convenience". When you do something not because it's absolutely unavoidable, but because it's easy to do. Later the situation changes... and you have a problem. That's related to our SMP woes: existing programs and languages are often quite inefficient in SMP environment because they include tons of unneeded synchronizations (where in UP is was "easy to do"). The only working solution is employed by kernel people: only introduce carefully designed very high-level boundary around you program (syscalls ABI) and keep internal interfaces unfrozen and slowly changing: then you can remove useless synchronization where it's not actually needed. Sadly few other projects are designed this way: more often then not it's bunch of very small programs with unclean, but frozen API. KDE tries to do things this way but they still have enormous ABI...