Opinions on Unladen Swallow?
Question:
What are your opinions and expectations on Google’s Unladen Swallow? From their project plan:
We want to make Python faster, but we
also want to make it easy for large,
well-established applications to
switch to Unladen Swallow.
- Produce a version of Python at least 5x faster than CPython.
- Python application performance should be stable.
- Maintain source-level compatibility with CPython
applications.
- Maintain source-level compatibility with CPython extension
modules.
- We do not want to maintain a Python implementation forever; we view
our work as a branch, not a fork.
And even sweeter:
In addition, we intend to remove the
GIL and fix the state of
multithreading in Python. We believe
this is possible through the
implementation of a more sophisticated
GC
It almost looks too good to be true, like the best of PyPy and Stackless combined.
More info:
- Jesse Noller: “Pycon: Unladen-Swallow”
- ArsTechnica: “Google searches for holy grail of Python performance”
Update: as DNS pointed out, there was related question: What is LLVM and How is replacing Python VM with LLVM increasing speeds 5x?
Answers:
I have high hopes for it.
-
This is being worked on by several people from Google. Seeing as how the BDFL is also employed there, this is a positive.
-
Off the bat, they state that this is a branch, and not a fork. As such, it’s within the realm of possibility that this will eventually get merged into trunk.
-
Most importantly, they have a working version. They’re using a version of unladen swallow right now for Youtube stuff.
They seem to have their shit together. They have a relatively detailed plan for a project at this stage, and they have a list of tests they use to gauge performance improvements and regressions.
I’m not holding my breath on GIL removal, but even if they never get around to that, the speed increases alone make it awesome.
I think the project has noble goals and with enough time (2-3 years), they will probably reach most of them.
They may not be able to merge their branch back into the trunk because Guido’s current view is that cpython should be a reference implementation (ie. it shouldn’t do things that are impossible for IronPython and jython to copy.) I’ve seen reports that this is what kept the cool parts of stackless from being merged into cpython.
They have a quarterly release. So not far away, wait and watch, let them come up with some thing more than just a plan.
If it indeed comes to be true, easy to do away with C and C++ even for performance intensive operations.
Even tho’ it is a Google sponsored Open Source project, surprisingly doesn’t involve Guido anywhere.
This question discussed many of the same things. My opinion is that it sounds great, but I’m waiting to see what it looks like, and how long it takes to become stable.
I’m particularly concerned with compatibility with existing code and libraries, and how the library-writing community responds to it. Ultimately, aside from personal hobby projects, it’s of zero value to me until it can run all my third-party libraries.
I think that a 5 times speed improvement is not all that important for me personally.
It is not an order of magnitude change. Although if you consume CPU power at the scale of Google it can be a worth while investment to have some of your staff work on it.
Many of the speed improvements will likely make it into cpython eventually.
Getting rid of the GIL is interesting in principle but will likely reveal lots of problems with modules that are not thread safe once the GIL is removed.
I do not think I will use Unladen Swallow any time soon but like how giving attention to performance may improve the regular Python versions.
Guido just posted an article to his twitter account that is an update to the Jesse Noller article posted earlier. http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/. Sounds like they are moving ahead as previously mentioned with python 3.
I’m sorry to disappoint you, but when you read PEP 3146 things look bad.
The improvement is by now minimal and therfore the compiler-code gets more complicated.
Also removing the GIL has many downsides.
Btw. PyPy seems to be faster then Unladen Swallow in some tests.
What are your opinions and expectations on Google’s Unladen Swallow? From their project plan:
We want to make Python faster, but we
also want to make it easy for large,
well-established applications to
switch to Unladen Swallow.
- Produce a version of Python at least 5x faster than CPython.
- Python application performance should be stable.
- Maintain source-level compatibility with CPython
applications.- Maintain source-level compatibility with CPython extension
modules.- We do not want to maintain a Python implementation forever; we view
our work as a branch, not a fork.
And even sweeter:
In addition, we intend to remove the
GIL and fix the state of
multithreading in Python. We believe
this is possible through the
implementation of a more sophisticated
GC
It almost looks too good to be true, like the best of PyPy and Stackless combined.
More info:
- Jesse Noller: “Pycon: Unladen-Swallow”
- ArsTechnica: “Google searches for holy grail of Python performance”
Update: as DNS pointed out, there was related question: What is LLVM and How is replacing Python VM with LLVM increasing speeds 5x?
I have high hopes for it.
-
This is being worked on by several people from Google. Seeing as how the BDFL is also employed there, this is a positive.
-
Off the bat, they state that this is a branch, and not a fork. As such, it’s within the realm of possibility that this will eventually get merged into trunk.
-
Most importantly, they have a working version. They’re using a version of unladen swallow right now for Youtube stuff.
They seem to have their shit together. They have a relatively detailed plan for a project at this stage, and they have a list of tests they use to gauge performance improvements and regressions.
I’m not holding my breath on GIL removal, but even if they never get around to that, the speed increases alone make it awesome.
I think the project has noble goals and with enough time (2-3 years), they will probably reach most of them.
They may not be able to merge their branch back into the trunk because Guido’s current view is that cpython should be a reference implementation (ie. it shouldn’t do things that are impossible for IronPython and jython to copy.) I’ve seen reports that this is what kept the cool parts of stackless from being merged into cpython.
They have a quarterly release. So not far away, wait and watch, let them come up with some thing more than just a plan.
If it indeed comes to be true, easy to do away with C and C++ even for performance intensive operations.
Even tho’ it is a Google sponsored Open Source project, surprisingly doesn’t involve Guido anywhere.
This question discussed many of the same things. My opinion is that it sounds great, but I’m waiting to see what it looks like, and how long it takes to become stable.
I’m particularly concerned with compatibility with existing code and libraries, and how the library-writing community responds to it. Ultimately, aside from personal hobby projects, it’s of zero value to me until it can run all my third-party libraries.
I think that a 5 times speed improvement is not all that important for me personally.
It is not an order of magnitude change. Although if you consume CPU power at the scale of Google it can be a worth while investment to have some of your staff work on it.
Many of the speed improvements will likely make it into cpython eventually.
Getting rid of the GIL is interesting in principle but will likely reveal lots of problems with modules that are not thread safe once the GIL is removed.
I do not think I will use Unladen Swallow any time soon but like how giving attention to performance may improve the regular Python versions.
Guido just posted an article to his twitter account that is an update to the Jesse Noller article posted earlier. http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/. Sounds like they are moving ahead as previously mentioned with python 3.
I’m sorry to disappoint you, but when you read PEP 3146 things look bad.
The improvement is by now minimal and therfore the compiler-code gets more complicated.
Also removing the GIL has many downsides.
Btw. PyPy seems to be faster then Unladen Swallow in some tests.