8 ms·

Unladen Swallow to be merged into Python 3

140 points by mcav 17y ago

mcav 17y ago
GVR's tweet: http://twitter.com/gvanrossum/status/9297047851 http://twitter.com/gvanrossum/status/9297047851 The PEP that was accepted: http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ Previous Discussion: http://news.ycombinator.com/item?id=1066283 http://news.ycombinator.com/item?id=1066283
- lpgauth 17y ago
  We seek the following from the BDFL: (...) - A pony.
  - Luyt 17y ago
    - A shrubbery.
andrewcooke 17y ago
unfortunately the numbers in the pep - http://www.python.org/dev/peps/pep-3146/#performance-retrospective 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 17y 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.
  - andrewcooke 17y 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...)
    - jonknee 17y ago
      "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.
- wingo 17y 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 17y ago
So have they removed the Python global interpreter lock? This is a mayor show-stopper server applications which require multiple threads.
- wmf 17y 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#Global_Interpreter_Lock http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Gl...
- inferno0069 17y 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 17y 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 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 17y 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 17y 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 17y 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.
- rbanffy 17y 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.
Snark7 17y 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 17y ago
  How is this a huge step backwards?
  - Snark7 17y 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 17y ago
  I'm not sure I follow you. Speed improvements to Python 3 will kill the language?
bhiggins 17y 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 17y 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.
- rbanffy 17y 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...

140 points by mcav 17y ago

mcav 17y ago

GVR's tweet: http://twitter.com/gvanrossum/status/9297047851 http://twitter.com/gvanrossum/status/9297047851 The PEP that was accepted: http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ Previous Discussion: http://news.ycombinator.com/item?id=1066283 http://news.ycombinator.com/item?id=1066283

lpgauth 17y ago
We seek the following from the BDFL: (...) - A pony.
- Luyt 17y ago
  - A shrubbery.

andrewcooke 17y ago

unfortunately the numbers in the pep - http://www.python.org/dev/peps/pep-3146/#performance-retrospective 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 17y 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.
- andrewcooke 17y 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...)
  - jonknee 17y ago
    "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.
wingo 17y 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 17y ago

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

wmf 17y 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#Global_Interpreter_Lock http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Gl...
inferno0069 17y 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 17y 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 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 17y 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 17y 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 17y 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.
rbanffy 17y 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.

Snark7 17y 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 17y ago
How is this a huge step backwards?
- Snark7 17y 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 17y ago
I'm not sure I follow you. Speed improvements to Python 3 will kill the language?

bhiggins 17y 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 17y 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.
rbanffy 17y 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...