如果PyPy快6.3倍，为什么我不应该使用PyPy而不是CPython？

本文翻译自：Why shouldn't I use PyPy over CPython if PyPy is 6.3 times faster?

I've been hearing a lot about the PyPy project. 我一直听到很多关于PyPy项目的消息。 They claim it is 6.3 times faster than the CPython interpreter on their site . 他们声称它比他们网站上的CPython解释器快6.3倍。

Whenever we talk about dynamic languages like Python, speed is one of the top issues. 每当我们谈论像Python这样的动态语言时，速度是最重要的问题之一。 To solve this, they say PyPy is 6.3 times faster. 为了解决这个问题，他们说PyPy的速度要快6.3倍。

The second issue is parallelism, the infamous Global Interpreter Lock (GIL). 第二个问题是并行性，臭名昭着的全球口译锁 （GIL）。 For this, PyPy says it can give GIL-less Python . 为此，PyPy表示它可以提供无GIL的Python 。

If PyPy can solve these great challenges, what are its weaknesses that are preventing wider adoption? 如果PyPy可以解决这些巨大的挑战，它的弱点是什么阻碍了更广泛的采用？ That is to say, what's preventing someone like me, a typical Python developer, from switching to PyPy right now ? 也就是说，什么阻止像我这样的人，一个典型的Python开发人员， 现在切换到PyPy？

---

#1楼

参考：https://stackoom.com/question/1HUtK/如果PyPy快-倍-为什么我不应该使用PyPy而不是CPython

---

#2楼

Because pypy is not 100% compatible, takes 8 gigs of ram to compile, is a moving target, and highly experimental, where cpython is stable, the default target for module builders for 2 decades (including c extensions that don't work on pypy), and already widely deployed. 因为pypy不是100％兼容，需要8 gig ram来编译，是一个移动目标，并且是高度实验性的，其中cpython是稳定的，模块构建器的默认目标是20年（包括在pypy上不起作用的c扩展） ），已经广泛部署。

Pypy will likely never be the reference implementation, but it is a good tool to have. Pypy可能永远不会成为参考实现，但它是一个很好的工具。

---

#3楼

The second question is easier to answer: you basically can use PyPy as a drop-in replacement if all your code is pure Python. 第二个问题更容易回答：如果您的所有代码都是纯Python，那么您基本上可以使用PyPy作为替代品。 However, many widely used libraries (including some of the standard library) are written in C and compiled as Python extensions. 但是，许多广泛使用的库（包括一些标准库）都是用C语言编写的，并编译为Python扩展。 Some of these can be made to work with PyPy, some can't. 其中一些可以与PyPy一起使用，有些则不能。 PyPy provides the same "forward-facing" tool as Python --- that is, it is Python --- but its innards are different, so tools that interface with those innards won't work. PyPy提供了与Python相同的“前向”工具---也就是说，它是Python ---但它的内脏是不同的，因此与这些内部接口的工具将无法工作。

As for the first question, I imagine it is sort of a Catch-22 with the first: PyPy has been evolving rapidly in an effort to improve speed and enhance interoperability with other code. 至于第一个问题，我认为它是第一个问题的第二个问题：PyPy一直在快速发展，以提高速度并增强与其他代码的互操作性。 This has made it more experimental than official. 这使它比官方更具实验性。

I think it's possible that if PyPy gets into a stable state, it may start getting more widely used. 我认为如果PyPy进入稳定状态，它可能会开始得到更广泛的使用。 I also think it would be great for Python to move away from its C underpinnings. 我也认为Python离开它的C基础是很好的。 But it won't happen for a while. 但它不会发生一段时间。 PyPy hasn't yet reached the critical mass where it is almost useful enough on its own to do everything you'd want, which would motivate people to fill in the gaps. PyPy还没有达到临界质量的地方是几乎足以对自己有用的做你想要的一切，这将激励人们以填补空白。

---

#4楼

1. PyPy, as others have been quick to mention, has tenuous support for C extensions . 正如其他人一直提到的那样，PyPy 对C扩展的支持很少 。 It has support, but typically at slower-than-Python speeds and it's iffy at best. 它有支持，但通常速度比Python速度慢，而且最多也是如此。 Hence a lot of modules simply require CPython. 因此很多模块只需要 CPython。 Cython and Numpy are awesome for numerics, and most people who actually need speed in Python are using those (+ Pandas, SciPy, etc.) heavily. Cython和Numpy对于数字来说非常棒 ，大多数真正需要Python速度的人都在大量使用它们（+ Pandas，SciPy等）。 Since they're either non-existent or tenuously supported and slow the people who need a fast Python often are better off with CPython both for speed and ease-of-use . 由于它们要么不存在，要么得到支持而且速度慢，需要快速Python的人通常会因为速度和易用性而更好地使用CPython 。
2. Python 3 support is experimental at the moment. Python 3支持 目前是实验性的。 has just reached stable! 刚刚达到稳定！ As of 20th June 2014, PyPy3 2.3.1 - Fulcrum is out ! 截至2014年6月20日， PyPy3 2.3.1 - Fulcrum已经淘汰 ！
3. PyPy sometimes isn't actually faster for "scripts", which a lot of people use Python for. PyPy有时实际上不是更快“脚本”，其中有很多人使用Python进行。 These are the short-running programs that do something simple and small. 这些是短期运行的程序，可以做一些简单而小巧的事情。 Because PyPy is a JIT compiler its main advantages come from long run times and simple types (such as numbers). 因为PyPy是一个JIT编译器，它的主要优点来自长运行时间和简单类型（例如数字）。 Frankly, PyPy's pre-JIT speeds are pretty bad compared to CPython. 坦率地说，与CPython相比， PyPy的JIT前速度非常差 。
4. Inertia . 惯性 。 Moving to PyPy often requires retooling, which for some people and organizations is simply too much work. 迁移到PyPy通常需要重组，这对某些人和组织来说太过分了。

Those are the main reasons that affect me, I'd say. 我会说，这些是影响我的主要原因。

NOTE: This question is ancient! 注意：这个问题很古老！ Avoid drawing conclusions from out-of-date information. 避免从过时的信息中得出结论。

---

#5楼

I did a small benchmark on this topic. 我在这个主题上做了一个小基准。 While many of the other posters have made good points about compatibility, my experience has been that PyPy isn't that much faster for just moving around bits. 虽然许多其他海报都对兼容性提出了很好的观点，但我的经验是PyPy并不是那么快就可以移动比特。 For many uses of Python, it really only exists to translate bits between two or more services. 对于Python的许多用途，它实际上只存在于两个或多个服务之间转换位。 For example, not many web applications are performing CPU intensive analysis of datasets. 例如，没有多少Web应用程序正在执行数据集的CPU密集型分析。 Instead, they take some bytes from a client, store them in some sort of database, and later return them to other clients. 相反，它们从客户端获取一些字节，将它们存储在某种数据库中，然后将它们返回给其他客户端。 Sometimes the format of the data is changed. 有时，数据的格式会发生变化。

The BDFL and the CPython developers are a remarkably intelligent group of people and have a managed to help CPython perform excellent in such a scenario. BDFL和CPython开发人员是一群非常聪明的人，并且能够帮助CPython在这种情况下表现出色。 Here's a shameless blog plug: http://www.hydrogen18.com/blog/unpickling-buffers.html . 这是一个无耻的博客插件： http ： //www.hydrogen18.com/blog/unpickling-buffers.html 。 I'm using Stackless, which is derived from CPython and retains the full C module interface. 我正在使用Stackless，它源自CPython并保留了完整的C模块接口。 I didn't find any advantage to using PyPy in that case. 在这种情况下，我没有发现使用PyPy有任何好处。

---

#6楼

That site does not claim PyPy is 6.3 times faster than CPython. 该网站并未声称PyPy比CPython快6.3倍。 To quote: 报价：

The geometric average of all benchmarks is 0.16 or 6.3 times faster than CPython 所有基准测试的几何平均值比CPython快0.16或6.3倍

This is a very different statement to the blanket statement you made, and when you understand the difference, you'll understand at least one set of reasons why you can't just say "use PyPy". 这是对你所做的一揽子陈述的一个非常不同的陈述，当你理解这些差异时，你至少会理解为什么你不能只说“使用PyPy”的一组理由。 It might sound like I'm nit-picking, but understanding why these two statements are totally different is vital. 这可能听起来像是挑剔，但理解为什么这两个陈述完全不同是至关重要的。

To break that down: 打破这种情况：

• The statement they make only applies to the benchmarks they've used. 他们所作的陈述仅适用于他们使用的基准。 It says absolutely nothing about your program (unless your program is exactly the same as one of their benchmarks). 它绝对没有说明你的程序（除非你的程序与他们的一个基准测试完全相同）。

• The statement is about an average of a group of benchmarks. 该声明大约是一组基准的平均值 。 There is no claim that running PyPy will give a 6.3 times improvement even for the programs they have tested. 没有人声称即使对于他们测试的程序，运行PyPy也会提高6.3倍。

• There is no claim that PyPy will even run all the programs that CPython runs at all , let alone faster. 没有人声称PyPy甚至会运行CPython运行的所有程序 ，更不用说更快了。