Unladen swallow项目计划：提高python速度5倍.
| 注: 根据已经release的两个版本来看,性能提升只有大概10%左右, 跟目标差距太大了吧... -------------------------------------- Unladen Swallow项目计划：提高Python速度5倍 | |
| 来源: Linux论坛 日期： 2009.03.29 10:05 (共有7条评论) 我要评论 | |
| Google的Python工程师发布了一个新项目，目的是让Python的速度提高至少5倍。新项目名叫Unladen Swallow，意图寻找新的Python解释程序虚拟机，新的JIT编译引擎。第一季度的目标是实现25-35%的性能提升，目前已经完成，代码发布在 Google Code 网站上。更多内容和介绍见内 目标 我们要让Python变的更快，同时我们也希望让大型的，完好的现存应用无痛苦的转而使用Unladen Swallow项目。 1. 创建一个比CPython速度至少快5倍的新Python版本。 2. Python应用的表现应该非常稳定。 3. 维持与CPython应用程序在源代码级别的兼容。 4. 维持于CPython扩展模块在源代码级别的兼容。 5. 我们并不是要维护一个长期的Python实现；我们把这个项目当作一个开发分支(branch)，而不是一个版本分支(fork)。 项目概括 为了实现我们对于性能和兼容性的目标，我们选择对CPython进行修改，而不是从零开始开发这个实现。值得强调的是，我们选择从 CPython 2.6.1着手：Python 2.6与2.4/2.5（当前为大多数有价值的应用使用）和Python 3.0(未来的终极版本)都有可以很好的共存。从一个CPython的版本着手可以是我们避免重新实现大量的内置函数，对象和标准库的模块，同时让我们重 用一些现存且常用的CPython的C语言扩展API。从一个2.x CPthon可以让我们更轻松的迁移现存的应用程序；假设我们从3.x开始，并且要求大型应用程序的维护者们率先迁移他们的程序，那对我们项目的受众来说 是不切实际的。 我们的主要工作是集中力量提高Python代码的执行速度，而不会在Python的运行时库上过多的努力。我们的长期计划是是使用一个创建在LLVM基础 上的JIT来代替CPython传统的虚拟机，同时尽量少的影响Python的运行模式的其他部分。通过观察，我们发现Python 的应用程序把大量的运行时间花费在了主eval循环。尤其是，即对例如操作码调度(opcode dispatch)这样虚拟机部件的微小调整也能对Python的运行性能产生重大影响。我们相信通过LLVM的JIT引擎把Python代码编译为机器 码将会带来更多的益处。 一些显著的好处： * 转向JIT能让我们把Python从基于堆栈的机(stack-based machine)转为一个基于寄存器的机(register machine)，实践证明这种转变提升了另一个类似语言的性能。 * 其他的先不提，单是消除对收发操作码(opcodes)的需要本身已经是一项胜利。请参考http://bugs.python.org/issue4753上一个当前CPython对操作码发送变化的敏感性的讨论。 * 目前的CPython虚拟机操作码接受/发送限制使进进一步的性能优化变得几乎不可能。举例来说，我们想实现数据类型回馈(type feedback)和动态的重新编译(dynamic recompilation ala SELF-93)，但是我们认为用CPython编译的二进制代码来实现多态性内联高速缓存（polymorphic inline caches)将是无法接受的慢。 * LLVM尤为值得注意。那是因为它为多个平台生成代码功能(codegen)的易用性，和它具有把C和C++编译为同种中间代码——这正是我们想要带给 Python的。它能够让内联和交错解析(inlining and analysis)成为可能，消除这个当前Python和C之间的障碍。 有了产生机器码的框架，我们就可以把Python编译为更加高效的实现。以以下这段代码为例： for i in range(3): foo(i) 目前它将被低效的翻译成这样 $x = range(3) while True: try: i = $x.next() except StopIteration: break foo(i) 一旦我们有了知道range()代表range()内置函数的办法，我们可以把它变为类似这样 for (i = 0; i < 3; i++) foo(i) 在C语言里，使用unboxed数据类型进行数学运算，可以把这个循环展开为 foo(0) foo(1) foo(2) 我们有意将Unladen Swallow的内部结构设计为支持多内核。服务器将来只会有越来越多的内核，我们要发掘这一点，从而可以在并行结构中完成更多的工作。例如，我们可以用 一个内核作为并行优化器，它能在代码运行的时候进行日益昂贵（重要）的代码优化，用另一个内核来执行代码本身。我们也在考虑实现一个并行的GC，利用另一 个内核来释放内存模块。由于大多数工业级的服务器都具有4到32个内核，我们相信这项优化的收益是一笔潜在的财富。然而，我们还是要关注高度并行的应用程 序的需要，而不能盲目的消耗掉这些内核。 强调一下，这里的很多领域已经被其他的一些动态语言考虑或者实现过了，例如jRuby，Rubinius和Parrot, 更包括像Jython，PyPy和IronPython这些其他的Python实现。我们正在从这些其他实现里寻找有关调试信息，正则性能以及其他提高动 态语言性能的点子。这是一条已经被很多人走过的路，我们需要尽量避免重新发明轮子的困境。计划蓝图 Unladen Swallow 将会每3个月发行一个新版本，发行期间进行bug修复。 2009 第一阶段 (Q1) Q1主要用来对显存的CPython实现进行相对小的修改。我们的目标是在目前的基线上实现25-35%的性能提升。这个阶段的目标是相对保守的，我们想尽可能快的给客户应用程序一些看得见的性能优化，而不是要他们等到整个项目完成。 2009 第二阶段 (Q2) Q2会集中力量来废除Python的虚拟机，并用一个具有相同功能的基于LLVM的实现将其代替。我们预期将会有一些性能提升，不过那不是2009Q2的主要任务。我们主要是要得到一个建立在LLVM之上的可以运行的东西。给它提速是本阶段之后的人物。 2009 第三阶段(Q3)以及将来 从Q3开始的任务将是“简单的“做好这些作业。我们不渴望做原创工作，而是尽可能的利用近30年来的研究成果。请移步相关论文来浏览我们打算实现内容的论文清单的一部分（远不及全部）。 我们计划强调对正则引擎何其他被确定为性能瓶颈的扩展模块的考虑。然而，正则表达式已经被确定为一个很好的目标并且会是我们考虑第一个进行优化的领域。 另外，我们打算去除Python的GIL和多线程的状态。我们相信通过实现一个更高级的GC，这一点是可以实现的，类似IBM的Recycler。 我们的长期目标是让Python的速度快到可以从把那些为了速度而使用C实现的类型重新用Python取代。 2009Q3准确的性能优化目标会在Q2的期间确定。 原文链接: http://code.google.com/p/unladen-swallow/wiki/Proj ectPlan 译文链接： http://danmarner.yo2.cn/unladen-swallow-project-pl an 原著： Google 译者： DaNmarner 欢迎转载，请保留原/译文链接。 ========================= Unladen Swallow项目计划——优化Python计划 注：所有引用资料的链接见相关论文。 来源：http://danmarner.yo2.cn/ |