它怎么可能击败CPython？
来自Google开源博客：
PyPy是Python中Python的重新实现，它使用先进的技术来获得比CPython更好的性能。 多年的努力终于得到了回报。 我们的速度结果经常超过CPython，范围从稍微慢一些，到实际应用程序代码的高达两倍，以便在小型基准测试中将速度提高10倍。
这怎么可能？ 哪个Python实现被用来实现PyPy？ CPython的？ PyPyPy或PyPyPyPy击败他们的分数有什么机会？
（在相关说明中......为什么有人会尝试这样的事情？）
Q1。 这怎么可能？
在某些情况下，手动内存管理（这是CPython用于计数的操作）可能比自动管理慢。
实施CPython解释器的局限性妨碍了PyPy可以做的某些优化（例如精细锁定）。
正如马塞洛提到的那样，JIT。 能够实时确认对象的类型可以节省您对多个指针取消引用的需求，从而最终达到您想要调用的方法。
Q2。 哪个Python实现被用来实现PyPy？
PyPy解释器在RPython中实现，它是Python的静态类型子集（语言而不是CPython解释器）。 - 详情请参阅https://pypy.readthedocs.org/en/latest/architecture.html。
Q3。 PyPyPy或PyPyPyPy击败他们的分数有什么机会？
这取决于这些假设口译员的实施情况。 如果其中一个例子拿走了源代码，对它进行了某种分析，并在运行一段时间后直接将其转换为紧密的特定目标汇编代码，我想它会比CPython快得多。
更新：最近，在一个精心设计的示例中，PyPy的性能超过了用gcc -O3编译的类似C程序。 这是一个人为的案例，但确实表现出一些想法。
Q4。 为什么有人会尝试这样的事情？
来自官方网站。 https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement
我们的目标是提供：
一个通用的翻译和支持框架
动态语言的实现，强调干净
语言规范与实现之间的分离
方面。 我们称之为RPython toolchain _。
一种兼容，灵活且快速的Python_语言实现，它使用上述工具链来启用新的高级高级特性，而无需编码低级细节。
通过以这种方式分离问题，我们的Python实现（以及其他动态语言）能够为任何动态语言自动生成一个即时编译器。 它还允许实现决策时使用混合匹配方法，包括历史上不受用户控制的许多方法，例如目标平台，内存和线程模型，垃圾收集策略以及应用的优化，包括是否拥有首先是一个JIT。
C编译器gcc用C实现，Haskell编译器GHC用Haskell编写。 你有没有理由不用Python编写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或PyPyPyPy的推测实际上没有任何意义，应该马上明白。 你有一个用RPython编写的解释器。 你可以将它翻译成能够快速执行Python的C代码。 这个过程停止了; 没有更多的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程序（也许）。
PyPy是用Python实现的，但是它实现了一个JIT编译器来即时生成本地代码。
在Python之上实现PyPy的原因可能是它仅仅是一种非常高效的语言，尤其是因为JIT编译器使得宿主语言的性能稍微不相关。
链接地址: http://www.djcxy.com/p/15165.html