PyPy は Python での Python の再実装であり、高度な技術を使用して CPython よりも優れたパフォーマンスを達成しようとします。長年の努力がついに報われました。私たちの速度の結果は、わずかに遅いものから、実際のアプリケーション コードで最大 2 倍の速度向上、小さなベンチマークで最大 10 倍の速度向上まで、CPython を上回ることがよくあります。
これはどのように可能ですか？PyPy の実装に使用された Python 実装は? Cパイソン? また、PyPyPy または PyPyPyPy がスコアを上回る可能性はどのくらいですか?
（関連するメモとして...なぜ誰かがこのようなことをしようとするのですか？）
Q1. How is this possible?
Manual memory management (which is what CPython does with its counting) can be slower than automatic management in some cases.
Limitations in the implementation of the CPython interpreter preclude certain optimisations that PyPy can do (eg. fine grained locks).
As Marcelo mentioned, the JIT. Being able to on the fly confirm the type of an object can save you the need to do multiple pointer dereferences to finally arrive at the method you want to call.
Q2. Which Python implementation was used to implement PyPy?
The PyPy interpreter is implemented in RPython which is a statically typed subset of Python (the language and not the CPython interpreter). - Refer https://pypy.readthedocs.org/en/latest/architecture.html for details.
Q3. And what are the chances of a PyPyPy or PyPyPyPy beating their score?
That would depend on the implementation of these hypothetical interpreters. If one of them for example took the source, did some kind of analysis on it and converted it directly into tight target specific assembly code after running for a while, I imagine it would be quite faster than CPython.
Update: Recently, on a carefully crafted example, PyPy outperformed a similar C program compiled with gcc -O3. It's a contrived case but does exhibit some ideas.
Q4. Why would anyone try something like this?
From the official site. https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement
We aim to provide:
a common translation and support framework for producing
implementations of dynamic languages, emphasizing a clean
separation between language specification and implementation
aspects. We call this theRPython toolchain_.a compliant, flexible and fast implementation of the Python_ Language which uses the above toolchain to enable new advanced high-level features without having to encode the low-level details.
By separating concerns in this way, our implementation of Python - and other dynamic languages - is able to automatically generate a Just-in-Time compiler for any dynamic language. It also allows a mix-and-match approach to implementation decisions, including many that have historically been outside of a user's control, such as target platform, memory and threading models, garbage collection strategies, and optimizations applied, including whether or not to have a JIT in the first place.
The C compiler gcc is implemented in C, The Haskell compiler GHC is written in Haskell. Do you have any reason for the Python interpreter/compiler to not be written in Python?
PyPyはPythonで実装されていますが、JITコンパイラーを実装して、ネイティブコードをその場で生成します。
Pythonの上にPyPyを実装する理由は、おそらくJITコンパイラーがホスト言語のパフォーマンスをいくらか無関係にするため、それが単に非常に生産的な言語であるためです。
PyPy は制限付き Python で書かれています。私の知る限り、CPython インタープリター上では実行されません。制限付き Python は、Python 言語のサブセットです。私の知る限り、PyPyインタープリターはマシンコードにコンパイルされているため、インストールすると実行時にPythonインタープリターを利用しません。
あなたの質問は、コードの実行中に PyPy インタープリターが CPython 上で実行されていることを期待しているようです。 編集:はい、PyPy を使用するには、最初に PyPy Python コードを C に変換し、gcc でビルドするか、jvm バイト コード、または .Net CLI コードに変換します。はじめにを参照してください