对《空载燕子》的看法？
您对 Google 的 Unladen Swallow 有什么看法和期望？ 从他们的项目计划来看：
我们想让 Python 更快，但是我们 也想让大的变得容易， 完善的应用程序 切换到空载燕子。
- 生成比 CPython 快至少 5 倍的 Python 版本。
- Python 应用程序性能应该稳定。
- 保持与 CPython 的源代码级兼容性 应用程序。
- 保持与 CPython 扩展的源代码级兼容性 模块。
- 我们不想永远维护 Python 实现； 我们认为 我们的工作是一个分支，而不是叉子。
甚至更甜蜜：
此外，我们打算删除 GIL 并修复状态 Python 中的多线程。 我们相信 这可以通过 实施更复杂的 气相色谱仪
它看起来好得令人难以置信，就像 PyPy 和 Stackless 的最佳组合一样。
更多信息：
- Jesse Noller："Pycon：Unladen-Swallow"
- ArsTechnica：“Google 搜索 Python 性能的圣杯”
更新：正如 DNS 指出的，有相关问题：什么是 LLVM 以及如何用 LLVM 替换 Python VM 将速度提高 5 倍？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我对此寄予厚望。
Google 的多名人员正在致力于此工作。 考虑到 BDFL 在那里也得到了应用，这是一个积极的结果。
他们立即声明这是一个分支，而不是一个分叉。 因此，它最终有可能合并到主干中。
最重要的是，他们有一个工作版本。 他们现在正在使用 unladen Sweat 的一个版本来播放 Youtube 内容。
他们似乎有共同点。 他们在这个阶段有一个相对详细的项目计划，并且有一个用于衡量性能改进和回归的测试列表。
我并没有对 GIL 的去除屏息以待，但即使他们从来没有抽出时间来解决这个问题，光是速度的增加就让它变得很棒。
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.
很抱歉让您失望，但是当您阅读 PEP 3146 时，事情看起来坏的。
到目前为止，改进很小，因此编译器代码变得更加复杂。
删除 GIL 也有很多缺点。
顺便提一句。 在一些测试中，PyPy 似乎比 Unladen Swallow 更快。
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.
这个问题讨论了许多相同的事情。 我的意见是，这听起来不错，但我正在等待看看它是什么样子，以及需要多长时间才能变得稳定。
我特别关心与现有代码和库的兼容性，以及库编写社区如何响应它。 最终，除了个人爱好项目之外，在它可以运行我所有的第三方库之前，它对我来说价值为零。
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.
我认为该项目有崇高的目标，并且只要有足够的时间（2-3年），他们可能会实现其中的大部分目标。
他们可能无法将他们的分支合并回主干，因为 Guido 当前的观点是 cpython 应该是一个参考实现（即它不应该做 IronPython 和 jython 无法复制的事情。）我看过报告这就是 stackless 中很酷的部分无法合并到 cpython 中的原因。
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.
Guido 刚刚在他的 Twitter 帐户上发布了一篇文章，这是对之前发布的 Jesse Noller 文章的更新。 http://jessenoller.com/2010/01 /06/unladen-swallow-python-3s-best-feature/。 听起来他们正在向前迈进，就像前面提到的 python 3 一样。
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.
他们每季度发布一次。 所以在不远处，等待并观察，让他们想出一些不仅仅是计划的东西。
如果确实如此，即使对于性能密集型操作，也很容易废除 C 和 C++。
尽管这是 Google 赞助的开源项目，但令人惊讶的是，它在任何地方都没有涉及 Guido。
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.
我认为 5 倍的速度提升对我个人来说并不是那么重要。
这不是一个数量级的变化。 尽管如果您消耗的 CPU 能力达到 Google 的规模，那么让您的一些员工参与其中可能是一项值得的投资。
许多速度改进最终可能会融入 cpython 中。
原则上删除 GIL 很有趣，但一旦删除 GIL，可能会暴露出非线程安全模块的许多问题。
我认为我不会很快使用 Unladen Swallow，但就像关注性能可以改善常规 Python 版本一样。
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.