Unladen Swallow的最后时光

最新推荐文章于 2020-07-20 14:21:28 发布

原创最新推荐文章于 2020-07-20 14:21:28 发布 · 274 阅读

CC 4.0 BY-SA版权

Unladen Swallow项目试图将LLVM优化引入CPython运行时，但最终宣告失败并停止开发。该项目曾计划通过引入LLVM运行时架构提高Python执行效率，然而LLVM的设计更适合静态语言，无法有效优化Python这类动态语言。团队现转向PyPy，该运行时自定义了JIT以提升性能。

unladen swallow尝试将LLVM优化引入到CPython运行时，但是去年却没有取得重大进展。现在，一篇回顾unladen swallow的文章已经确认了这个项目的死亡，不会再进行开发。

它的目标曾经是多么野心勃勃；引入LLVM运行时架构作为CPython的解释器，然后将其作为一个选项，能够在JIT编译的时候打开。LLVM被用在一些高端项目中，例如全新的Clang模块编译器以及LLDB调试器，这些都在Apple的Xcode4中被采用。这些高端用户案例看起来非常诱人：

最开始选择使用LLVM是因为那个时候我们都没用x86汇编语言的丰富经验，而我们又真的希望能够支持x86和x86_64，如果可能的话，将来也希望支持ARM架构。我们也坚信LLVM是一个更加健壮的JIT，起码比现在看起来应该健壮很多。Apple就在其产品中使用了JIT引擎，我们认为这是一个积极的信号，它表示LLVM也能够在我们的项目中很好工作。使用LLVM帮助我们很快地起步，但是它却很快成为了我们的负担，我们不得不在修复大量的对JIT进行支持的bug中结束我们的工作。不过它也给我们提供了诸多特性的支持，我们不需要开发新特性，但是我们也需要时间来做这件里程碑式的工作。

众所周知，编译器工具链是非常难以做到完美无bug的；最近有一篇论文的主题就是寻找和理解C编译器bug，它展示了一些在工具链不断开发和完善的过程中发现的非常著名的bug。不过，unladen swallow的这些问题却和这篇论文关系不大，它更多和例如Python这些解释性语言本身的性质相关，而不是单纯的代码问题：

不幸的是，从设计之初，LLVM就是被作为一个静态编译器，优化器以及后端。LLVM的代码生成和优化功能非常优秀，但是开销非常昂贵。这些优化都是着力于类似于C这样的静态语言生成的中间表示。而大多数对Python的优化却需要更高层的知识，例如程序在前一个迭代中是如何执行的，LLVM并不能在此发挥作用。

在JVMJIT中使用的很多优化技术都需要了解程序是如何运行的，这样才能更好地在数据收集之后执行后续JIT操作。这个功能的最大好处就是方法调用的内联化；但是，我们也要明白JVM并不能够在程序执行前静态地完成这项工作，相反，一些其他的优化技术简化代码直到产生内联方法。例如运行一个基于Python的JIT，那么将函数调用内联化将是一个加速性能的非常关键的技术，这些同样需要一些时间来将这个技术加入到LLVM架构中。

（值得提及的是，LLVM现在正在进行更强大的随机测试，这个消息是在2010年11月的LLVM开发者大会上宣布的）

但是，这些对unladen swallow都无济于事。也许问题可能出现在资助上；大多数Python的用户都不会在性能要求非常严格的任务中使用Python，所以优化并不会太多。其次，CPython的关键开发者们对于LLVM和产生的结果兴趣寥寥，甚至有可能在默认选项中禁用并且在未来放弃这个功能。

VMKit的目的是在LLVM运行时上构建高层语言，它的特性包括对象支持，自动内存管理，不过这个工具是服务于Java或者.NET运行时。

unladen swallow小组现在将所有的精力转到PyPy上。这个是另外一个Python运行时，它自定义了JIT以加速执行效率。Python提速需要考虑的问题之一便是并不是所有的代码都是“纯”Python；有许多原生扩展是使用C编写，这就需要妥善处理。（使用Java实现的Python运行时，Jython就不直接支持CPython中利用C实现的特性，而是会使用Java重新实现）但是和其他解释语言一样，也许最影响执行效率的便是全局解释锁，它阻碍了多线程Python代码的运行。很不幸的是，PyPy或者unladen swallow都不能改变这个现实。

LLVM2.9预计于下周发布。不过这并不代表着其他的项目，例如Rubinius，将会使用LLVM作为运行时引擎。

查看英文原文：The Last Flight of the Unladen Swallow