BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Pyston——基于LLVM和现代JIT技术的开源Python实现

| 作者 臧秀涛 关注 2 他的粉丝 发布于 2014年4月22日. 估计阅读时间: 4 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

本月初,Kevin Modzelewski在Dropbox技术博客撰文宣布了他们正在开发的一款开源Python实现——Pyston。该项目的目标是开发出一款高性能的Python实现,使Python跻身如C++等传统系统级语言所统治的领域。

Dropbox内部有很多项目是用Python编写的。Python之父Guido van Rossum从Google离职后也加入了这家公司。随着业务规模的增长,性能问题也愈加突出。虽然通过其他语言改写应用可以获得性能改进,但出于对Python的钟爱,Dropbox的工程师们希望改变Python的性能。在使用静态编译做了一些实验之后,他们放弃了这种策略。鉴于Google的v8对JavaScript性能的极大改进,他们决定采用类似的技术来改进Python的性能。

现在已经有了一些采用了JIT技术的Python实现,比如PyPy,它使用的是基于Trace的JIT技术,大幅改进了Python的性能,再如Jython和IronPython,它们则构建于大量应用JIT技术的成熟虚拟机之上。那为什么还要引入一种新实现呢?文中给出的解释是:

简单地说,这是因为我们认为前景最好的技术与现有实现不兼容。例如,由于巨大的性能优势,JavaScript世界已经从基于Trace的JIT转向基于方法的JIT(每次编译一个方法)。在Python上是否有同样的优势尚不得而知,但因为这两种方法从根本上是不兼容的,所以要回答这个问题,唯一的方法是构建一个新的基于方法的JIT。

还有一点,他们计划使用保守的垃圾收集器,以便高效支持扩展模块

当然,从零开始创建一个语言实现工作量非常大。不过Pyston准备基于LLVM构建,这会方便很多。

文中还介绍了Pyston的工作方式:

从高层看,Pyston接受解析好的Python代码,并将其转换为LLVM中间代码(IR)。然后IR经由LLVM优化器处理,再被传送给LLVM JIT引擎,最后得到可执行的机器代码。

Pyston的代码已经在Github上开放出来,Dropbox希望和Python及JIT社区合作推进其开发。项目页面上还介绍了Pyston的一些技术特色,比如编译层次、栈上替换和内联等,感兴趣的读者可以参考。

在Pyston之前,Google的几位工程师曾发起过Unladen Swallow项目,目标是将Python的性能提高5倍,主要想法是为 CPython 添加一个基于 LLVM 的 JIT 编译器,但是该项目以失败告终。关于该项目的经验与教训,有两篇文章可以参考:1.Unladen Swallow 的失败与教训,以及关于 Pypy;2. Unladen Swallow Retrospective

关于Pyston,在Hacker News上也有一些讨论。比如haberman指出,基于方法的JIT编译器其实是更为传统的方式,而基于Trace的最近5~10年才流行起来的。尽管V8确实采用的是基于方法的JIT,Mozilla也放弃了基于Trace的JIT TraceMonkey,但是LuaJIT却是最快的动态语言实现之一,而且采用的就是基于Trace的JIT。LuaJIT的作者Mike Pall认为TraceMonkey没有取得很好的性能,更大程度上是因为尝试将Trace绑到现有的虚拟机上,而不是因为基于Trace的JIT技术的缺点。

Facebook也为优化其PHP应用的性能做了很多工作,现在的解决方案是基于JIT的HHVM,这种方案可以说是成功的。那Pyston的前景如何呢?我们拭目以待。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

怎么样 by 张章 鸥翔鱼游

那Pyston的前景如何呢?

Re: 怎么样 by 臧 秀涛

Pyston离真正可用还远,具体可以跟踪该项目的github页。

pyston的重点不是使用LLVM吧 by 李 夏光

Unladen Swallow项目 的失败教训里提到:

Unfortunately, LLVM in its current state is really designed as a static compiler optimizer and back end. LLVM code generation and optimization is good but expensive. The optimizations are all designed to work on IR generated by static C-like languages. Most of the important optimizations for optimizing Python require high-level knowledge of how the program executed on previous iterations, and LLVM didn't help us do that.
An example of needing to apply high-level knowledge to code generation is optimizing the Python stack access. LLVM will not fold loads from the Python stack across calls to external functions (ie the CPython runtime, so all the time). We eventually wrote an alias analysis to solve this problem, but it's an example of what you have to do if you don't roll your own code generator.
LLVM also comes with other constraints. For example, LLVM doesn't really support back-patching, which PyPy uses for fixing up their guard side exits. It's a fairly large dependency with high memory usage, but I would argue that based on the work Steven Noonan did for his GSOC that it could be reduced, especially considering that PyPy's memory usage had been higher.


一个不争的事实是 LLVM 本身的优化大都工作在最底层,LLVM 不会去试图理解 Python 语言里那些动态特性,要想利用 LLVM,必须要先手工完成一些更高层级的 Python 的语言分析与优化。

pyston既然也在用LLVM,完成的就是这部分工作吧

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT