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 作为运行时引擎。
评论