PyPyがデフォルトPythonになったら良いのに

Summary

1. pypyはJITコンパイラを備え、CPU処理とスレッディングで大きな効果を持つ
   1. PyPyはGIL制約があるが、スレッディングが他の言語同様の並列処理として機能する。
      1. IronPythonやJythonはGILの影響なし。
      2. MultiThreadより非同期を使うのが吉かと。
2. NumbaやCythonに比べ、最も簡単に高速化でき、影響範囲も大きい。最良のecosystemである。
3. ただし、(Py以外すべての言語の)プログラム処理はI/Oバウンドの問題もあるため、高速化のeffortは限定的である。
   1. とはいえ、この限定的な最適化が大きな意味を持つ人達もいるだろう。
      1. Juliaへ流れる方は、純粋に数学的処理をしたい方であろう。そういった方々はPythonの演算が遅く、NumbaやCythonによる最適化を非効率と思われるのかもしれない。
4. Pythonとしてのインタプリタの変更だけで、高速化の恩恵を得られるのは大変ありがたい。 pypy用のbuild済みパッケージが配布されて、CPythonと同じ様に使用できるなら、Pypyはもっと一般化されるかもしれない。
   1. 少なくとも、「Pythonが遅い」という多言語とのベンチマークで指さされない(/ミスリードされない)だろう^^;。
   2. アプリの速度を決める要因は、CPU以外にも多数(各種I/Oバウンド(DB,net,storage etc.)、並列化（CPyはGIL制約がある))ある。実は、総合的には他の言語とそれほど差異はないのじゃないかもしれない。
   3. むしろ、Pythonは、パッケージが充実しており、その豊富なパッケージ(例：Cacheや分散処理(ray))を駆使するほうが効果的な事もありそう。
   4. とはいえ、トラブル多い(イメージの)Numba, コードの手直しが必要なCythonとは違い、導入するだけで計算処理が大幅に高速化されるpypyは大変ありがたい(二度言ってる...)
5. 現状のpypyは実務レベルでは在ると思うが、適用できるのは小規模のアプリに限定かもしれない。
   1. pypyのパッケージはソースからのbuildが必要な物が多い(例: pandas, numpy?, scipy)ためLinuxがbest。DEVパッケージがaptなどで配布されているからbuild環境構築が容易。
   2. DockerやVMを併用する事でWin/MacOSもpypyを大規模なPy製アプリにも利用できるが、これでは万人向けとは"未だ"言えない。
6. 結論: Pypyの将来が楽しみ。
   1. PyPyのAdvantageをCPythonに取り込んで頂けるのも可。
   2. Python速度5倍化計画

---

イントロ

PyPyに惹かれています。

私のサブ組織は規模が小さいので、Pythonだけ使っていたい。

なのにPythonはとても遅い。(計算系なので)なんでこんなに遅いのかな、と思う...。

他の主要言語最適化されている。どこかの記事に、PHP8の最適化の最終兵器としてJITコンパイラを組み込んだという話が在りました。Pythonには全く最適化がない。

(最適化の-Oパラあるが、assert除去くらい？)

各言語vsベンチマークの結果も相手は、JITコンパイラといった最適化がされているので、Pythonも最適化されたらいい勝負できると思います。実際、CPythonの代わりに、Pypyをベンチマークテストに参加させて欲しい！と思う事もしばしば。

Pythonが遅いと何が問題か

1. アプリの動作にもっさり感が生じてしまう。
2. 常に計算量を考慮しながらコーディングする必要あり？
   1. クラスを利用したマジックは、コード量減らすが、計算量増やす場合があり、余計手間がかかる
   2. 計算量の考慮しなくて良いなら、冗長なコードが書け、コード全体をわかりやすくできる。

Pypyにすると何が便利？

既存Pythonをpypyに置き換えるだけで高速化されると助かる場面も多いかと思います。

なんせ、計算処理では、C++言語やJavaでさえ速度面でまさる事もあるのですから。
(C++/Cのコードより、スコアで上回るのはJITコンパイラによるCPUアーキテクチャ最適化だろう、たぶん、と考えております。)

I/O面ではCPythonに劣る事もあるとはいえ、インタプリタの切替は、venvで切り替えて使ってらっしゃる皆さんにとっては、簡単です。なので、JITコンパイラ付きpypyがデフォルトになったら、RustやJuliaへの移行/学び直しが減る恐れがあります。これって恩恵を受けれる人多そうです。
(I/Oは、普通に組んだら、差異は少ないはずなので。）

最近のpypyは良くなっている

過去にPyPyはモジュールが入らないというデメリットが大きかったのですが、Numpy, Scipyが入るといった問題の解決が見られます。 Dockerを使えば、更にインストールできるモジュールは増えます。

注) miniconda/anacondaのpypyも使えるのかも。 minicondaのpypy3でpypy3.9 error related to pybind11::error_already_set, unexpected indentのエラーに合ったので、使えないものと思い込んでいたのかも...というわけで、anacondaのpypyは意外と使えるかもしれません。

---

計算基盤にはpypyには、良さそう。Numbaは少し前まで例外処理(try-cache)使えなかったし、Cythonはアノテーション指定ができて便利になりましたが、公式によるとPurePhythonモードは20-50%しか性能アップしないとか。それなら、インタプリタをpypyへ切り替えるだけで最適化されたら楽ですよね。

一方、pypyへの導入効果が低いのは、I/Oバウンドに時間を要するところでしょうか。
また、アプリの規模が大きくなり、様々なモジュールをつかう中、pypy非対応のモジュールを代替できない場合はpypy自体を使えません。
たとえば、orjsonはpypyに対応しておらず、別のに変えましたが、pypy3.9でscipyで落ちるのは、私の計算用コードでは、代替できずでした。
そもそも、pypyが効力を有するのはCPU計算周りで、I/Oバンド周りは効果が低いようです。

一方、非同期処理/Threadは効果があるかもです。

• Async HTTP benchmarks on PyPy3

---

• 追記 @ 2022.4.15
• CPythonが遅いという記事は散見されますが、ベンチマークにおいて、比較して早い動的言語の殆どがJITコンパイラ内包であるため、Pythonは、CPythonではなくpypyで比較すべきでは、と思う。
• pypyは頑張ってくださっているが、CPythonと違う挙動?があるのは確か。
  • 筆者はメモリリークに合った
  • "Godot for python"筆者作の "Godot for pypy"は不備?が多いといったメッセをプラグイン内に記している
• C言語が早いのは確かだが、筆者みたいな片手間プログラマでは、JITコンパイラを使った方がCythonで作ったコードより早い事も多いみたい。

---

Pypyのメリット

1. 導入だけ早くなる
   1. 公式サイトによるとCPythonに比べ、平均4.2倍。多分、この値は数理計算やforなので、実務コードでは未計測です。
      1. ただ、CythonやらNumbaより楽です、Webシステムには良さそう。
2. メンテもされている？
   1. PyPy Releasesを見ると頻繁に更新はされています。
   2. ただし、内部がC/C++で書かれている場合には恩恵はないでしょう。
3. Cythonを適用しにくい環境で助かる？
   1. pyximport()を使って、効率化も図ってらっしゃる方もいると思うのですが、コードの改変を要します。
      1. 完全な個人であればよいのですが、将来的にコード共有したい場合は、Cythonの理解を相手にも求めることになる。それを避ける事ができる。
4. マルチスレッドの性能が効く(GIL制約を受けない)
   1. CPythonはスレッド化してGIL制約で、I/Oバンドくらいしか速度UPしないのではないでしょうか。
   2. 余り意味はありませんが。
5. デバッグもできる。
   1. PyCharmPro2022.02.01時点で確認。

PyPyのデメリット

1. モジュールのインストールでコケる (非対応を除き、Dockerで解決。）
   1. これはPｙPyの問題ではなく、モジュールが別ライブラリや言語(例:C言語,C++,Rust)を使っている事に依る。
      1. つまり、モジュールを使うために、SUBモジュール同封のCPython用と違って、PyPyは一からbuildが必要。
   2. モジュール配布者がpypy用にもモジュールを提供してもらえるのが最良なんじゃないかな。
2. I/O周りはCPythonと変わらないか、遅いこともままあるかも(2022/4/24追記)。
3. PyPyに対応してないモジュールがある。
   1. orjson。　-> mashallowで解決？
   2. streamlit
   3. ray?(分散/並列実行パッケージなど)
      1. pip install rayで入らない。
   4. Numba...結構痛い。
4. Debugがほんの少し手間？
   1. PyCharm(2022.2.19現在版)で問題なくDebugはできる。
      1. (ただし、CPythonと比べて、余計なStackが挟まれている。今後改善されるでしょう。)
      2. PyPyのDebugに対応してくれた関係者の方々にはホント感謝。
5. Numpy,Scipyも問題なく導入できるが、Docker必須？
   1. Pandas, Scikit-learnなども可。
   2. ただし、DockerなどでDevパッケージを利用できる必要がある。逆をいえば、Dockerがあれば。
   3. PyPy(CPython3.9互換版)では、Scipy.optimizeが読み込めないエラーあり(2022.4.23現在)。
      1. CPython3.8互換版のpypyでは本問題はない。
6. 起動が少し遅い？

おまけ

不思議に思ったのが,遅いCPythonでPython言語を再実装したPypyが、C言語で開発したCPythonより早い？？？(そんな馬鹿な!)と思ってましたので、ほんと目からウロコです。