我听说了很多关于PyPy项目的事情。他们声称它比他们网站上的CPython解释器快6.3倍。
每当我们谈论像Python这样的动态语言时,速度是首要问题之一。为了解决这个问题,他们说PyPy要快6.3倍。
第二个问题是并行性,即臭名昭著的全局解释器锁(GIL)。为此,PyPy说它可以提供无gil的Python。
如果PyPy可以解决这些巨大的挑战,那么它的弱点是什么?也就是说,是什么阻止了像我这样的典型的Python开发人员现在转向PyPy ?
我听说了很多关于PyPy项目的事情。他们声称它比他们网站上的CPython解释器快6.3倍。
每当我们谈论像Python这样的动态语言时,速度是首要问题之一。为了解决这个问题,他们说PyPy要快6.3倍。
第二个问题是并行性,即臭名昭著的全局解释器锁(GIL)。为此,PyPy说它可以提供无gil的Python。
如果PyPy可以解决这些巨大的挑战,那么它的弱点是什么?也就是说,是什么阻止了像我这样的典型的Python开发人员现在转向PyPy ?
当前回答
问:如果与CPython相比,PyPy可以解决这些巨大的挑战(速度、内存消耗、并行性),那么它的弱点是什么?
答:首先,几乎没有证据表明PyPy团队可以解决一般的速度问题。长期的证据表明,PyPy运行某些Python代码比CPython慢,这个缺点似乎深深植根于PyPy。
其次,在相当大的一组情况下,当前版本的PyPy比CPython消耗更多的内存。所以PyPy还没有解决内存消耗的问题。
PyPy是否解决了上面提到的巨大挑战,并且通常会比CPython更快,更少的内存消耗,对并行更友好,这是一个悬而未决的问题,短期内无法解决。有些人打赌,PyPy将永远无法提供一个通用的解决方案,使其在所有情况下都能主导CPython 2.7和3.3。
如果PyPy在总体上比CPython更好,这是值得怀疑的,影响其更广泛采用的主要弱点将是它与CPython的兼容性。还有一些问题,比如CPython在更广泛的cpu和操作系统上运行,但与PyPy的性能和CPython兼容性目标相比,这些问题要重要得多。
问:为什么我现在不能用PyPy替换CPython ?
答:PyPy并不是100%与CPython兼容,因为它没有在底层模拟CPython。一些程序可能仍然依赖于CPython的独特特性,而这些特性在PyPy中是不存在的,比如C绑定、Python对象和方法的C实现,或者CPython垃圾收集器的增量特性。
其他回答
简单来说:PyPy提供了CPython所缺乏的速度,但牺牲了它的兼容性。然而,大多数人选择Python是因为它的灵活性和“包含电池的”特性(高兼容性),而不是因为它的速度(尽管它仍然是首选)。
对于许多项目,不同的python之间在速度方面实际上是0%的差异。这是由工程时间主导的,所有的python都有相同数量的库支持。
PyPy已经有Python 3支持一段时间了,但根据Anthony Shaw 2018年4月2日在HackerNoon发布的这篇文章,PyPy3仍然比PyPy (Python 2)慢几倍。
对于许多科学计算,特别是矩阵计算,numpy是更好的选择(参见常见问题:应该安装numpy还是numpypy?)
Pypy不支持gmpy2。您可以使用gmpy_cffi,不过我还没有测试它的速度,该项目在2014年发布了一个版本。
对于Project Euler问题,我经常使用PyPy,对于简单的数值计算,通常从__future__导入除法就足以满足我的目的,但截至2018年,Python 3支持仍在开发中,最好的选择是在64位Linux上。截至2018年12月的最新版本Windows PyPy3.5 v6.0处于测试阶段。
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. For many uses of Python, it really only exists to translate bits between two or more services. For example, not many web applications are performing CPU intensive analysis of datasets. 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.
BDFL和CPython开发人员是一群非常聪明的人,他们设法帮助CPython在这种情况下表现出色。这是一个无耻的博客:http://www.hydrogen18.com/blog/unpickling-buffers.html。我使用的是Stackless,它源自CPython,并保留了完整的C模块接口。在这种情况下,我没有发现使用PyPy的任何优势。
注意:与2013年提出这个问题时相比,现在的PyPy更成熟,支持也更好。避免从过时的信息中得出结论。
PyPy, as others have been quick to mention, has tenuous support for C extensions. It has support, but typically at slower-than-Python speeds and it's iffy at best. Hence a lot of modules simply require CPython. PyPy doesn't support numpy. Some extensions are still not supported (Pandas, SciPy, etc.), take a look at the list of supported packages before making the change. Note that many packages marked unsupported on the list are now supported. Python 3 support is experimental at the moment. has just reached stable! As of 20th June 2014, PyPy3 2.3.1 - Fulcrum is out! PyPy sometimes isn't actually faster for "scripts", which a lot of people use Python for. 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's pre-JIT speeds can be bad compared to CPython. Inertia. Moving to PyPy often requires retooling, which for some people and organizations is simply too much work.
我想说,这些是影响我的主要原因。