PyPyの速度が6.3倍速いのであれば、なぜCPythonよりもPyPyを使用してはいけないのでしょうか。
PyPy プロジェクトについて多くのことを聞いています。彼らはそれが CPython インタプリタの 彼らのサイトに - 6.3倍速いと主張します 。
私たちがPythonのような動的言語について話すときはいつでも、スピードは一番の問題の1つです。これを解決するために、彼らはPyPyが6.3倍速いと言っています。
2番目の問題は並列性、悪名高い Global Interpreter Lock （GIL）です。これに関して、PyPyは GILのないPythonを提供できると言っています 。
PyPyがこれらの大きな課題を解決できるとしたら、より広範な採用を妨げている弱点は何ですか？つまり、私のような典型的なPython開発者がPyPy 今すぐ に切り替えられないのはなぜですか。
- 他の人がすぐに言及したように、PyPyにはC拡張機能の継続的なサポートがあります。それはをサポートしていますが、通常はPythonよりも遅い速度であり、せいぜい不確かです。したがって、多くのモジュールは単純にrequireCPythonです。 CythonとNumpyは数値ではawesomeであり、Pythonで実際に速度が必要なほとんどの人はそれら（+パンダ、SciPyなど）を多用しています。それらは存在しないか、サポートが不十分で遅いため高速Pythonを必要とする人は、速度と使いやすさの両方でCPythonを使用したほうがよいことがよくあります。
- Python 3のサポート
現時点では実験的です。安定しました！ 2014年6月20日の時点で、 PyPy3 2.3.1-Fulcrumは出ています ！ - 多くの人がPythonを使用する「スクリプト」の場合、PyPyは時々は実際には高速ではありません。これらは、シンプルで小さなことを行う短時間実行プログラムです。 PyPyはJITコンパイラーであるため、その主な利点は、実行時間が長いことと単純な型（数値など）にあります。率直に言って、PyPyのJIT以前の速度はかなり悪い CPythonと比較して。
- 慣性。 PyPyに移行するには、多くの場合、ツールの変更が必要になります。これは、一部の人々や組織にとっては、あまりにも多くの作業です。
これらが私に影響を与える主な理由だと思います。
注：この質問は古くからあります！古い情報から結論を引き出すことは避けてください。
そのサイトはnotPyPyがCPythonよりも6.3倍速いと主張しています。引用するには：
すべてのベンチマークの幾何平均は、CPythonより0.16または6.3倍高速です。
これは、あなたが作成したブランケットステートメントとは非常に異なる非常にステートメントであり、違いを理解すると、少なくとも1セットの理由を理解できます「PyPyを使用」とは言えません。私はちょっとピッキングしているように聞こえるかもしれませんが、これら2つのステートメントがまったく異なる理由を理解することが不可欠です。
それを分解するには：
彼らが行う声明は、使用したベンチマークにのみ適用されます。それはあなたのプログラムについて絶対に何も言わない（あなたのプログラムが彼らのベンチマークの1つとまったく同じでない限り）。
このステートメントは、ベンチマークのグループのaverageに関するものです。 PyPyを実行すると、テストしたプログラムでも6.3倍の改善が得られるという主張はありません。
PyPyがCPythonが実行するすべてのプログラムをすべて実行するという主張もありません。
Pypyは100％互換ではないので、コンパイルには8ギガのRAMを必要とします。これは、cpythonが安定しているという非常に実験的な、非常に実験的なものです。 ）、そしてすでに広く展開されています。
Pypyはおそらくリファレンス実装になることはないでしょうが、持っておくのは良いツールです。
2番目の質問の答えは簡単です。すべてのコードが純粋なPythonである場合、基本的にcanドロップイン置換としてPyPyを使用します。ただし、広く使用されている多くのライブラリ（標準ライブラリの一部を含む）はCで記述され、Python拡張としてコンパイルされます。これらのいくつかはPyPyで動作するようにできますが、できないものもあります。 PyPyはPythonと同じ「前向き」ツールを提供します---つまり、Python ---ですが、その内部は異なるため、それらの内部とインターフェイスするツールが勝ちました動作しません。
最初の質問に関して、私はそれが最初のキャッチ22のようなものだと思います：PyPyは、速度を改善し、他のコードとの相互運用性を強化するために急速に進化しています。これにより、公式よりも実験的なものになりました。
PyPyが安定した状態になると、より広く使用されるようになる可能性があると思います。また、PythonがCの基盤から離れることは素晴らしいことだと思います。しかし、それはしばらくは起こりません。 PyPyは、それがalmost必要なすべてを実行するのに十分なだけで十分に有用な臨界質量にまだ達していません。
私はこのトピックに関して小さなベンチマークを行いました。他のポスターの多くが互換性について良い点を挙げていますが、私の経験では、PyPyはビットを移動するだけではそれほど速くはありません。 Pythonの多くの用途では、実際には2つ以上のサービス間でビットを変換することしかできません。たとえば、データセットのCPU集中分析を実行しているWebアプリケーションはあまりありません。代わりに、クライアントから数バイトを取り出し、それらを何らかのデータベースに格納して、後で他のクライアントに返します。データの形式が変わることがあります。
BDFLとCPythonの開発者は非常に知的な人々の集団であり、CPythonがそのようなシナリオで優れたパフォーマンスを発揮するのを手助けしてくれました。これは恥知らずなブログプラグです： http://www.hydrogen18.com/blog/unpickling-buffers.html 。私はStacklessを使用しています。これはCPythonから派生したもので、完全なCモジュールインターフェイスを保持しています。その場合、私はPyPyを使用することに利点はありませんでした。
Q：CPythonと比較してPyPyがこれらの大きな課題（速度、メモリ消費、並列性）を解決できる場合、その採用が広く採用されていない弱点は何ですか？
A：まず、PyPyチームが速度の問題を一般的に解決できるという証拠はほとんどありません。長期的な証拠は、PyPyが特定のPythonコードをCPythonよりも遅く実行することを示しており、この欠点はPyPyに非常に深く根付いているようです。
第二に、PyPyの現在のバージョンは、かなり大きなケースでCPythonよりもはるかに多くのメモリを消費します。そのため、PyPyはメモリ消費の問題をまだ解決していません。
PyPyが前述の大きな課題を解決し、一般的に一般的にCPythonよりも高速で、メモリの空腹が少なく、並列処理に優しいかどうかは、短期的には解決できない未解決の問題です。一部の人々は、PyPyがgeneralソリューションを決して提供できず、すべての場合でCPython 2.7および3.3を支配できるようになると賭けています。
PyPyが一般的にCPythonよりも優れている場合（これは疑わしい）、その広範な採用に影響する主な弱点は、CPythonとの互換性です。また、CPythonがより広い範囲のCPUおよびOSで実行されるという事実などの問題もありますが、これらの問題はPyPyのパフォーマンスおよびCPython互換性の目標に比べてそれほど重要ではありません。
Q：なぜCPythonをPyPyに置き換えてドロップできないのですか？
A：PyPyは、CPythonを内部でシミュレートしていないため、CPythonと100％互換ではありません。 Cバインディング、Python object＆methodsのC実装、またはCPythonのガベージコレクターのインクリメンタルな性質など、一部のプログラムはPyPyにはないCPythonのユニークな機能に依存する場合があります。
CPythonには参照カウントとガベージコレクションがありますが、PyPyにはガベージコレクションしかありません。
そのため、オブジェクトは先に削除される傾向があり、__del__はCPythonではより予測可能な方法で呼び出されます。一部のソフトウェアはこの動作に依存しているため、PyPyに移行する準備ができていません。
他のソフトウェアのいくつかは両方で動作しますが、未使用のオブジェクトは早く解放されるので、CPythonではより少ないメモリを使用します。 （これがどれほど重要であるか、そして他のどの実装の詳細がメモリ使用量に影響するかを示すための測定値はありません。）
私は例を見つけました、そこではPyPyがPythonより遅いです。しかし：Windows上でのみ。
C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop
C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop
だから、あなたがPyPyについて考えるなら、Windowsを忘れてください。 Linuxでは、あなたは素晴らしい加速を達成することができます。例（1から1,000,000の間のすべての素数をリストします）：
from sympy import sieve
primes = list(sieve.primerange(1, 10**6))
これは、PythonよりPyPyの方が10倍（！）速くなります。しかし窓にはありません。それは3倍速い。
多くのプロジェクトでは、速度の点で異なるpythonsの間に実際に0％の違いがあります。それは、エンジニアリング時間が大部分を占めており、すべてのpythonが同じ量のライブラリサポートを持っているということです。
これを簡単にするために：PyPyはCPythonにはないスピードを提供しますが、その互換性を犠牲にします。しかし、ほとんどの人は、その柔軟性と「バッテリー内蔵」機能（高い互換性）のためにPythonを選びますが、速度のためではありません（それでもなお好まれています）。
PyPyはしばらくの間Python 3をサポートしてきましたが、2018年4月2日のAnthony Shawによるこの HackerNoonの投稿 によると、PyPy3はまだPyPy（Python 2）より数倍遅いです。
多くの科学計算、特に行列計算では、numpyがより良い選択です（ FAQ：numpyとnumpypyのどちらをインストールすべきですか？ を参照）。
Pypyはgmpy2をサポートしません。 あなたは代わりに gmpy_cffi を使うことができますが、私はそのスピードをテストしておらず、プロジェクトは2014年に1つのリリースを持っていました。
Project Eulerの問題では、私はPyPyを頻繁に使用します。そして単純な数値計算では、私の目的にはfrom __future__ import divisionで十分ですが、Python 3サポートは2018年時点でまだ行われています。 2018年12月現在のWindows PyPy3.5 v6.0は、ベータ版です。