PyPy – 它怎么可能击败CPython？
来自Google开源博客 ：
PyPy是Python中Python的重新实现，使用先进的技术来获得比CPython更好的性能。 多年的努力终于得到了回报。 我们的速度结果经常超过CPython，范围从稍微慢一些，到实际应用程序代码的高达两倍，在小型基准testing中加速达到10倍。
这怎么可能？ 哪个Python实现被用来实现PyPy？ CPython ？ PyPyPy或PyPyPyPy打败他们的分数有什么机会？
（在一个相关的说明…为什么有人会尝试这样的事情？）
Q1。 这怎么可能？
在某些情况下，手动内存pipe理（这是CPython用于计数的操作）可能比自动pipe理慢。
CPython解释器的实现中的局限性排除了PyPy可以做的某些优化（例如细粒度的锁）。
正如马塞洛提到的那样，JIT。 能够实时确认一个对象的types可以节省您需要做多个指针取消引用，最终到达您想要调用的方法。
Q2。 哪个Python实现被用来实现PyPy？
PyPy解释器在RPython中实现，它是Python的静态types子集（语言而不是CPython解释器）。 – 有关详细信息，请参阅https://pypy.readthedocs.org/en/latest/architecture.html 。
Q3。 PyPyPy或PyPyPyPy打败他们的分数有什么机会？
这将取决于这些假设的口译员的执行情况。 如果其中一个例子拿了源码，对它进行了一些分析，并在运行了一段时间之后直接将其转换成紧密的特定目标程序集代码，我想它会比CPython快得多。
更新：最近，在一个精心devise的例子中 ，PyPy比使用gcc -O3编译的类似的C程序性能gcc -O3 。 这是一个人为的案例，但是确实展现了一些想法。
Q4。 为什么有人会这样做？
从官方网站。 https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement
我们的目标是提供：
一个通用的翻译和支持框架
dynamic语言的实现，强调干净
语言规范与实现之间的分离
方面。 我们称之为RPython toolchain_。Python_语言的兼容，灵活和快速实现，它使用上述工具链来启用新的高级高级function，而不必编码低级细节。
通过这种方式分离问题，我们的Python和其他dynamic语言的实现能够为任何dynamic语言自动生成一个即时编译器。 它还允许混合搭配的方式来执行决策，包括历史上不受用户控制的许多方法，例如目标平台，内存和线程模型，垃圾收集策略以及应用的优化，包括是否拥有一个JIT首先。
C编译器gcc用C实现，Haskell编译器GHC用Haskell编写。 Python解释器/编译器是否有任何理由不能用Python编写？
“PyPy是Python中Python的重新实现”是一个颇具误导性的方式来描述PyPy，恕我直言，尽pipe它在技术上是正确的。
PyPy有两个主要部分。
- 翻译框架
- 翻译
翻译框架是一个编译器。 它将RPython代码编译为C（或其他目标），自动添加诸如垃圾收集和JIT编译器等方面。 它不能处理任意的Python代码，只能使用RPython。
RPython是普通Python的一个子集; 所有的RPython代码都是Python代码，但不是相反的方式。 RPython没有正式的定义，因为RPython基本上就是“PyPy翻译框架可以翻译的Python的子集”。 但为了进行翻译，RPython代码必须是静态types的 （types是推断的，你不要声明它们，但它仍然严格地是每个variables的一种types），你不能做像声明/修改函数/在运行时也是类。
这个解释器是用RPython编写的一个普通的Python解释器。
由于RPython代码是普通的Python代码，因此可以在任何Python解释器上运行它。 但PyPy的速度声明没有一个是以这种方式运行的; 这只是一个快速的testing周期，因为翻译翻译需要很长时间。
据了解，PyPyPy或PyPyPyPy的推测实际上没有任何意义。 你有一个用RPython编写的解释器。 你把它翻译成C代码来快速执行Python。 那里的过程停止了; 没有更多的RPython通过再次处理来加速。
所以“PyPy如何比CPython更快”也变得相当明显。 PyPy有更好的实现，包括一个JIT编译器（如果没有JIT编译器，我相信这通常不会那么快，这意味着PyPy对于易受JIT编译影响的程序只会更快）。 CPython从来没有被devise成一个高度优化的Python语言实现（尽pipe他们试图使它成为一个高度优化的实现，如果你按照不同的方式）。
PyPy项目的真正创新之处在于它们不需要手动编写复杂的GCscheme或JIT编译器。 他们直接在RPython中编写解释器，对于所有的RPython比Python低一级，它仍然是一个面向对象的垃圾收集语言，比C高得多。然后翻译框架自动添加GC和JIT。 所以翻译框架是一个巨大的努力，但它同样适用于PyPy python解释器，但它们改变了它们的实现，允许更多的实验自由来提高性能（不用担心引入GC错误或更新JIT编译器来应付变化）。 这也意味着当他们开始实施Python3解释器时，它将自动获得相同的好处。 还有其他任何用PyPy框架编写的解释器（其中有不同阶段的抛光）。 所有使用PyPy框架的解释器都自动支持框架支持的所有平台。
因此，PyPy项目的真正好处是尽可能地分离为dynamic语言实现一个高效的平台独立解释器的所有部分。 然后在一个地方提出一个好的实现，可以在许多口译员中重复使用。 这不是像“我的Python程序现在跑的更快”这样的直接获胜，但是对未来来说这是一个很好的前景。
它可以更快地运行你的Python程序（也许）。
PyPy是用Python实现的，但是它实现了一个JIT编译器来实时生成本地代码。
在Python之上实现PyPy的原因可能是它是一种非常高效的语言，特别是因为JIT编译器使得宿主语言的性能有些不相关。
PyPy是用受限制的Python编写的。 就我所知，它不在CPython解释器之上运行。 受限制的Python是Python语言的一个子集。 AFAIK，PyPy解释器被编译成机器码，所以在安装时它不会在运行时使用python解释器。
您的问题似乎预计PyPy解释器在执行代码时正在CPython之上运行。 编辑：是的，要使用PyPy，您首先要将PyPy python代码翻译为C，并使用gcc，jvm字节代码或.Net CLI代码进行编译。 请参阅入门
