Unladen Swallow to be merged into Python 3 | Hacker News Reader

Unladen Swallow to be merged into Python 3

lwn.net

140 pointsmcav28 comments

The current perfomance of Unladen Swallow is only marginally better while the memory consumption is a lot worse. And I think a lot more work will be required to improve perfomance and memory usage of Unladen Swallow...

PyPy is another interesting project that seems to be under active development ( nightly benchmarks against CPython http://buildbot.pypy.org/plotsummary.html ). I don't know how this decision on supporting Unladen Swallow will affect PyPy, but it would be a shame if it died as it has a lot of interesting ideas - - and I think it has a lot more potential than Unladen Swallow.

From the accepted PEP:

"We view reducing memory usage as a blocking issue for final merger into the py3k branch. We seek guidance from the community on an acceptable level of increased memory usage."

I think that the current consensus is that unladen-swallow was aimed at a short term performance boost, while pypy has more ambitious long-term goals. While the CPython branch may be the current "standard", there's no reason that another runtime couldn't surpass it and become defacto.

I don't think PyPy has a chance at becoming the standard the way things are going now.

Their funding has ended, and I don't think they will manage to pony up another million+ in funding after 5 years. PyPy isn't compatible with C modules, and can be up to 5x as slow as Cpython (according to their own benchmarks). Making unladen-swallow the python standard will probably cause a brain-drain and make others hesitant to support PyPy.

Performance is heavily dependent on use cases. PyPy is not compatible with libraries written in C while this is a core design decision for Unladen Swallow.

To use a car analogy, PyPy is a race car that is not street legal, while Unladen Swallow is an European sports coupé that is slightly faster than the mild-mannered CPython sedan we all know and love while using somewhat more fuel.

As far as car analogies go, this one looks pretty good.

How can you tell it's not an African sports coupé?

I don't know ... what's the difference?

The African sports coupé is not migratory.

PyPy implements ctypes and can work with C libraries.

PyPy has a lot of potential, but it won't be usable in the near future, and it will certainly not die since it's primary goal is to implement Python in Python (or come as close as possible). And consider they haven't reached the speed of CPython (which by all means, it's slow) although the project started in 2004. Surely if they'll get there, it will be awesome, but in the meantime there's no reason to not take a more pragmatic approach.

On the other hand, Unladen Swallow is using LLVM, which may create the necessary tools for LLVM to be a suitable VM for dynamic languages (versus the JVM / CLR).

I consider this to be exciting news actually ... Python 3 doesn't offer me much, and I won't switch to a less supported Python version unless I have a bigger incentive (right now I'm happy with Python 2.6).

Maybe Unladen Swallow won't be able to achieve it's goals (5x faster), but if it's 3x faster with only a reasonable increase in memory consumption, than it's worth it.

GVR's tweet: http://twitter.com/gvanrossum/status/9297047851

The PEP that was accepted: http://www.python.org/dev/peps/pep-3146/

Previous Discussion: http://news.ycombinator.com/item?id=1066283

We seek the following from the BDFL:

(...)

- A pony.

- A shrubbery.

unfortunately the numbers in the pep - http://www.python.org/dev/peps/pep-3146/#performance-retrosp... - aren't as exciting as you might hope: Our initial goal for Unladen Swallow was a 5x performance improvement over CPython 2.6. We did not hit that, nor to put it bluntly, even come close.

yeah, i thought the same. But i think the work that was done so far built the base for further improvements. They were "distracted" by building other features into llvm, profiling tools and such.

I think, even if the speed stays the same now, there will be good opportunities to real speed ups in the future.

i hope so (although i find the whole thing a bit odd - why is it being merged now, if the work was mainly in fixing llvm; why not spend another year and hit the numbers? pypy has been steadily improving, and while people have said there's room for both, this smells a bit political...)

"This PEP proposes to integrate Unladen Swallow into CPython's development tree in a separate py3k-jit branch, targeted for eventual merger with the main py3k branch. While Unladen Swallow is by no means finished or perfect, we feel that Unladen Swallow has reached sufficient maturity to warrant incorporation into CPython's roadmap. We have sought to create a stable platform that the wider CPython development team can build upon, a platform that will yield increasing performance for years to come."

It's not going right in.

It's a remarkable study in the power of marketing: people hear "unladen swallow, llvm" and they think "fast"; but the reality is not that simple.

So have they removed the Python global interpreter lock? This is a mayor show-stopper server applications which require multiple threads.

No. "we are no longer as optimistic about our chances of removing the GIL completely." http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Gl...

From the PEP: "Unladen Swallow has focused on improving the performance of single-threaded, pure-Python code. We have not made an effort to remove CPython's global interpreter lock (GIL); we feel this is separate from our work, and due to its sensitivity, is best done in a mainline development branch. We considered making GIL-removal a part of Unladen Swallow, but were concerned by the possibility of introducing subtle bugs when porting our work from CPython 2.6 to 3.x."

I'm pretty confident that this is the nail in Python 3's coffin. It just shows how out-of-touch GvR and Google are with Python users. For a while, Python 3 was on a track to becoming a more mature language, but this is a huge step backwards. Politics at Google have ruined the future of Python 3. In contrast, Python 2.x just keeps on getting better and better.

How is this a huge step backwards?

The arguments have been laid out elsewhere, so let me summarize:

1. The memory requirements are massive 2. The chosen approach is substantially more complex than CPython 3. The claimed performance improvements have not been demonstrated

But much worse than all of these, it shows that the future of Python 3 is in the hands of Google managers, not an independent project leader.

I'm not sure I follow you. Speed improvements to Python 3 will kill the language?

At first I thought this was going to be a huge reason for people to migrate over to Python 3... Now I'm worried that it'll actually be another reason not to (due to size increase and only moderate speed increase), but I sure hope I'm wrong!

I think unladen swallow is going to be a boon to Python and dynamic languages in general. The additional work the unladen swallow team has had to do to get LLVM into a position where it could support a dynamic language has slowed them down, but I'm confident that the effort will end up producing substantial speed boosts while also leaving behind an awesome general purpose VM in LLVM for other people to build on. It's not there yet, but it will be.

It will be on a separate branch until they have achieved some of the speed and memory goals - so far, most of the work was in the plumbing. I am optimistic.

Maybe, just maybe, Plone 6 will run on top of Zope 3 and Python 3.

One can dream...

Reply on news.ycombinator.com