Unladen Swallow 的最后时光

  • Alex Blewitt
  • 杨晨

2011 年 4 月 2 日

话题:JavaRuby编程语言Python架构DevOps语言 & 开发

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

JavaRuby编程语言Python架构DevOps语言 & 开发