从谷歌开源博客:
PyPy是Python的重新实现 在Python中，使用高级技术 努力获得更好的表现 比CPython的。多年的辛勤工作 终于有了回报。我们的速度 结果经常击败CPython，测距 从稍微慢一点，到 实车加速可达2倍 应用程序代码，以加速高达
这怎么可能呢?哪个Python实现被用来实现PyPy?CPython的吗?PyPyPy或PyPyPyPy超过他们分数的几率有多大?
(与此相关的是……为什么会有人尝试这样的事情?)
PyPy是用Python实现的，但它实现了一个JIT编译器来动态生成本机代码。
在Python之上实现PyPy的原因可能只是因为它是一种非常高效的语言，特别是因为JIT编译器使宿主语言的性能有些无关紧要。
Q1。这怎么可能呢?
在某些情况下，手动内存管理(这是CPython对其计数所做的)可能比自动管理慢。
CPython解释器实现的局限性排除了PyPy可以做的某些优化(例如。细粒度锁)。
正如马塞洛提到的，JIT。能够动态地确认对象的类型可以使您不必执行多个指针解引用来最终到达想要调用的方法。
Q2。哪个Python实现被用来实现PyPy?
PyPy解释器是在RPython中实现的，RPython是Python(语言而不是CPython解释器)的静态类型子集。-详细信息请参考https://pypy.readthedocs.org/en/latest/architecture.html。
第三季。PyPyPy或PyPyPyPy超过他们分数的几率有多大?
这将取决于这些假设解释器的实现。例如，如果他们中的一个人获得源代码，对其进行某种分析，并在运行一段时间后将其直接转换为严格的目标特定的程序集代码，我想它会比CPython快得多。
最近，在精心制作的例子上，PyPy的性能超过了用gcc -O3编译的类似C程序。这是一个虚构的案例，但确实展示了一些想法。
gcc -O3
第四季度。为什么会有人这么做?
来自官方网站。https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement
我们的目标是: 一个用于生成的通用翻译和支持框架 动态语言的实现，强调干净的 语言规范和实现之间的分离 方面。我们称之为RPython toolchain_. 一个兼容的、灵活的、快速的Python_ 语言，使用上述工具链来启用新的高级 高级特性而不必编码低级特性 李细节。< / p > < / > 通过这样分离关注点，我们实现了Python -和 其他动态语言——是能够自动生成的 适用于任何动态语言的即时编译器。它还允许 混合匹配实现决策的方法，包括许多 从历史上看不受用户控制的，例如 目标平台、内存和线程模型、垃圾收集 策略，以及应用的优化，包括是否
我们的目标是:
一个用于生成的通用翻译和支持框架 动态语言的实现，强调干净的 语言规范和实现之间的分离 方面。我们称之为RPython toolchain_.
RPython toolchain
一个兼容的、灵活的、快速的Python_ 语言，使用上述工具链来启用新的高级 高级特性而不必编码低级特性 李细节。< / p > < / >
C编译器gcc是用C语言实现的，Haskell编译器GHC是用Haskell编写的。你有什么理由不让Python解释器/编译器用Python编写吗?
PyPy是用Restricted Python编写的。据我所知，它并不运行在CPython解释器之上。Restricted Python是Python语言的一个子集。AFAIK, PyPy解释器被编译为机器码，因此在安装时它不会在运行时使用python解释器。
“PyPy是Python中的Python的重新实现”是一种相当具有误导性的描述PyPy的方式，恕我直言，尽管它在技术上是正确的。
PyPy有两个主要部分。
翻译框架是一个编译器。它将RPython代码编译为C语言(或其他目标)，自动添加垃圾收集和JIT编译器等方面。它不能处理任意的Python代码，只RPython。
RPython是普通Python的子集;所有RPython代码都是Python代码，而不是反过来。RPython没有正式的定义，因为RPython基本上只是“可以被PyPy的翻译框架翻译的Python的子集”。但是为了被翻译，RPython代码必须是静态类型(类型是推断的，你不声明它们，但它仍然严格地每个变量一个类型)，你也不能在运行时声明/修改函数/类之类的事情。
这个解释器就是一个用RPython编写的普通Python解释器。
因为RPython代码是普通的Python代码，所以可以在任何Python解释器上运行它。但PyPy声称的速度都不是来自于这样运行;这只是一个快速测试周期，因为翻译解释器需要长时间。
了解了这一点，就应该立即明白，关于PyPyPy或PyPyPy的推测实际上没有任何意义。你有一个用RPython编写的解释器。您可以将其转换为C代码，从而快速执行Python。这个过程在那里停止;没有更多的RPython来加速再次处理它。
所以“PyPy怎么可能比CPython快”也变得相当明显。PyPy有一个更好的实现，包括一个JIT编译器(我认为，如果没有JIT编译器，它通常没有那么快，这意味着PyPy只对容易受到JIT编译影响的程序更快)。CPython从未被设计为Python语言的高度优化实现(尽管他们确实试图使其成为高度优化实现，如果你了解区别的话)。
PyPy项目真正的创新之处在于，他们不手动编写复杂的GC方案或JIT编译器。他们用RPython相对简单地编写解释器，尽管RPython的级别比Python低，但它仍然是一种面向对象的垃圾收集语言，比c的级别高得多。然后，翻译框架自动添加了GC和JIT之类的东西。因此，翻译框架是巨大的的努力，但它同样适用于PyPy python解释器，无论他们改变他们的实现，允许在实验中有更多的自由来提高性能(不用担心引入GC错误或更新JIT编译器来应对这些变化)。这也意味着当他们开始实现Python3解释器时，它将自动获得相同的好处。以及使用PyPy框架编写的任何其他解释器(其中有许多处于不同的优化阶段)。所有使用PyPy框架的解释器都自动支持该框架支持的所有平台。
因此，PyPy项目的真正好处是(尽可能多地)分离出为动态语言实现高效的平台独立解释器的所有部分。然后在一个地方提出一个好的实现，可以在许多解释器中重复使用。这不是像“我的Python程序现在运行得更快了”那样的立竿见影的胜利，但它是未来的一个美好前景。
并且它可以更快地运行你的Python程序(也许)。
