Unladen Swallow to be merged into Python 3

http://lwn.net/Articles/373801/

by mcav • 16 years ago

140 28 16 years ago

lwn.net

mcav• 16 years ago

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

lpgauth• 16 years ago

We seek the following from the BDFL:

(...)

- A pony.

Luyt• 16 years ago

- A shrubbery.

andrewcooke2• 16 years ago

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.

buster• 16 years ago

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.

andrewcooke2• 16 years ago

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...)

wingo• 16 years ago

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.

roschdal• 16 years ago

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

wmf• 16 years ago

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...

inferno0069• 16 years ago

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."

amix• 16 years ago

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.

callahad• 16 years ago

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."

ominous_prime• 16 years ago

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.

codexon• 16 years ago

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.

rbanffy3• 16 years ago

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.

bch• 16 years ago

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

dalke• 16 years ago

PyPy implements ctypes and can work with C libraries.

bad_user• 16 years ago

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.

Snark72• 16 years ago

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.

icey• 16 years ago

How is this a huge step backwards?

Snark72• 16 years ago

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.

steveklabnik• 16 years ago

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

bhiggins• 16 years ago

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!

jmtulloss• 16 years ago

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.

rbanffy3• 16 years ago

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...

Unladen Swallow to be merged into Python 3

Related Stories