Dropbox正开发的开源Python 解释器Pyston的实例分析

这期内容当中小编将会给大家带来有关Dropbox正开发的开源python 解释器Pyston的实例分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

大家好，我非常激动宣布 Pyston，这是一个正在由 Dropbox 开发的开源 Python 解释器。 这个项目的目标是产生一个高性能的 Python 解释器，使 Python 也能用于那些被如 c++ 这样的传统系统语言占据的领域。

在 Dropbox ，我们热爱 Python ，尝试用它来做一切可以做的事情。然而随着规模的的变大和要处理的问题越来越多，我们开始发现继续使用 Python 而要达到我们的性能目标有时候极其困难。有时用另外一门语言重写也起不了多大作用。我本人非常喜欢 Python ， 每次当我们决定重写什么东西的时候我都很受伤，所以我想为它做一点什么。在静态编译上做了一些无用功后，我们到处查资料然后发现 JIT 技术在 javascript 上非常成功，尤其 是 Chrome 的 V8 引擎大大地改善了 Javascript 的性能。我们希望通过同样的技术也能在 Python 上达到相同的性能提升。

Pyston 现在仍然处于初期阶段，还不能投入使用。但我们希望早点在它的生命周期之初就公布并开源出来，这样我们就能和 Python 和 JIT 社区来合作开发了。太多的细节在这篇博客写不下，但我们想说一下我们为什么需要一个新的 Python 实现，以及讲一点点 Pyston 是怎么工作的。

为什么选择实现一个新的 Python 解释器

早就已经有了一大堆使用 JIT 技术的 Python 实现：PyPy 使用它的 tracing JIT 来提高性能；Jython 和 IronPython 都是构建在广泛支持 JIT 的虚拟机上的。所以为什么我们认为还值得开始创造一个新的实现呢？

简单来说，是因为我们认为绝大多数有前景的技术都和现有的实现不兼容。比如，在 Javascript 界就因为强大的性能优势从 tracing JIT 切换到 method-at-a-time JIT 。对 Python 是否有同样的性能优势还有待商榷，但由于这两种途径从根本上都是和现有的实现不兼容的，所以答案只能是构建一个新的 method-at-a-time JIT。

另外一个区别是我们对传统的垃圾回收器有计划地使用来高效地支持拓展模块。同样，我们现在也无法知道这是否是一种更好的方法，但这个决定对一个很难在现有的实现下进行测试的 JIT 来说是必不可少的。

从零开始的坏处就是，创造一个新的语言的实现毋庸置疑是一个巨大的任务。幸运的是， 有助于这个过程的一些工具已经开始出现了。尤其是 Pyston 是构建在 LLVM 之上的，使得我们不需要自己处理细节就可以生成上层的高质量代码。尽管如此，一个新的 Python 实现还是一个巨大 的工程，所以 Pyson 将不会马上就能投入使用。

它是怎么工作的

从顶层看，Pyston 将解析好的 Python 代码转换成 LLVM 中间代码。然后中间代码就通过 LLVM 的优化然后传递给 LLVM 的 JIT 引擎，产生可执行的机器代码。LLVM 包含许多优化步骤和机制，使得它能产生非常快的代码。

然而问题是 LLVM 不能推出 Python 代码，因为动态语言不得不把所有底层的行为都隐藏在类型分派(Type Dispatch)后。为了解决这个问题，Pyston 采用类型推断：虽然证明一个变量将会是某个特别的类型通常是不可能，但是 Pyston 经常可以根据一些确定的事实来预测某个对象会是什么类型。一旦做出 了一个预测，Pyston 将在运行时检测这个预测，在预测所对应的快速分支和预测失败所对应的慢速分支之间进行选择。

Pyston 还包含许多其他的现代技术，比如为快速查找属性和快速调用方法而设计的隐藏类和内联缓存。你可以在 GitHub 页面上找到更多的技术细节，以及一篇单独讲述这些技术细节的博文。

现状

Pyston 仍然处于初始阶段，只支持 Python 语言的一个最小子集。拿基准测试数据来说话是不怎么公平的，因为 1) Pyston 不支持足够大的基准测试，所以这不具备代表意义。2) Pyston 不支持所有运行时特性（包括一些可能带来减速的特性），所以这不是一个同类的比较。 在这两点注意事项下，Pyston 在性能上通常可以击败 CPython，但是仍然弱于 PyPy。

上述就是小编为大家分享的Dropbox正开发的开源Python 解释器Pyston的实例分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注编程网Python频道。