Python 3.14がメタルにコンパイルされる – インタプリタなし

pon ponは、Rustで書かれたPython 3.14用のJITおよびAoTネイティブコンパイラ兼ランタイムです。インタプリタもバイトコードもありません。すべてのモジュールはruffパーサーで解析され、1つの共有IR（中間表現）に低下され、Craneliftを通じてマシンコードにコンパイルされます。これは、プロセスの内部で（pon run）ジャストインタイムで行われるか、または事前に（pon build）スタンドアロンのネイティブ実行可能ファイルにコンパイルされます。メモリは参照カウントではなくGreen Teaガベージコレクタによって管理され、正確性はCPython v3.14.0に対するバイト単位で正確な差分ハーネスによって強制されます。 最終的な目標は、Python版のbun/v8です。CPythonテストスイートをパスし、CPythonをはるかに超えるマルチティアJITを実行し、単一バイナリ実行可能ファイルを配布し、標準でバッテリー（パッケージマネージャー、ツール）を含んだランタイムです。このプロジェクトは活発に開発中であり、現在の状況と将来の方向性についてはステータスを参照してください。 クイックスタート # JIT: parse → IR → Cranelift → run, in-process printf 'def add(a, b): return a + b print("hello, world") print(add(2, 3)) ' > hello.py cargo run -p pon -- run hello.py # AoT: same IR through cranelift-object, linked into a native executable cargo run -p pon -- build hello.py -o hello ./hello どちらのパスもCPythonが出力するのと同じバイトを出力します。このプロパティは野心的ではなく、適合性スイート（適合性参照）の出口ゲートです。 pon run <file> [args] pon build <file> -o <out> [--allow-dynamic] [--opt] [--target <triple>] pon repl pon -c 'print(40 + 2)' pon - < script.py アーキテクチャ 1つのIR、2つのバックエンド、1つのランタイムABI。ベースラインJIT、最適化JIT、AoTの各ティアは同じIRに低下し、同じpon_*ヘルパー関数を呼び出します。 source.py │ │ ruff parser (pinned 0.14.0, PythonVersion::PY314) │ AST ──> PON IR (pon-ir, every tier for one IR) │ ├── pon run: pon-codegen ──> cranelift-jit ──> native code in process │ tier-0 baseline (all boxed) │ tier-1 typed: inline caches, OSR, background compile │ └── pon build: pon-codegen ──> cranelift-object ──> object file ──> linked executable pon-runtime (object model, builtins, NULL-sentinel pon_* ABI) pon-gc (Green Tea garbage collector) オブジェクトモデル：CPythonのヒープオブジェクトレイアウトからrefcountヘッダーを除いたもの。エラーはABIをNULLセンチネルとして横断し、アンワインドしません。整数は任意精度です（PyLongの背後にあるnum-bigint）。タグ付きの小さな整数用の高速パスが型付きティアに着陸しています。 ティアリング：tier-0は型フィードバックなしで全てのボックス化されたものをコンパイルし、正確性のベースラインです（PON_TIER0_ONLY=1で強制）。ランタイムヘルパーは最初の実行からのフィードバックセル型プロファイルを供給します。ホットな関数はバックグラウンドスレッドで再コンパイルされ、実行中のループはオンスタック置換を通じて最適化されたコードに入ります。 GC：Green Teaコレクタが全てのPythonオブジェクトを所有します。Tier-0はセーフポイントでのレジスタフラッシュトランポリンを備えた保守的なスタックスキャンを使用します。型付きティアは、正確なCraneliftユーザーのスタックマップにアップグレードします。 ワークスペース クレート 役割 pon-ir ruffベースのフロントエンド：Python 3.14を解析し、共有PON IRに低下させる pon-codegen IR → Cranelift CLIF、全てのバックエンドとティアで共有される pon-jit プロセス内コンパイル、ティアリング、インラインキャッシュ、OSR、バックグラウンドコンパイル pon-aot cranelift-objectバックエンド：オブジェクトファイルとリンクされたネイティブ実行可能ファイル pon-runtime オブジェクトモデル、ビルトイン、標準ライブラリネイティブモジュール、pon_*ヘルパーABI pon-gc Green Teaガベージコレクタ pon-abi codegenとランタイム間で共有されるABI型 pon ponバイナリ：run/build/replエントリーポイント + パッケージマネージャー（インデックスクライアント、リゾルバ、wheel/sdistインストール） pon-conformance 差分適合性スイート、ファジング、ベンチマーク、フロアラチェット 全ての依存関係はルートCargo.tomlの[workspace.dependencies]の下に一度だけ宣言されます。メンバークレートは継承するだけです（AGENTS.md参照）。 適合性 & テスト 正確性の契約は差分です。コーパスモジュールは、ponがCPython v3.14.0（TZ=UTC、PYTHONHASHSEED=0）とバイト単位で同一の出力を生成した場合のみ合格します。合格セットはコミットされたフロアファイルにラチェットされ、CIはフロアを下回るいかなるリグレッションも失敗させます。 Suite | What it measures | Committed floor ---|---|--- cpython | corpus modules, JIT, byte-exact vs CPython 3.14 | 244 modules (conformance-floor.json) cpython-aot-subset | same corpus compiled AoT and executed as native binaries | 206 modules (aot-parity-floor.json) cpython-full | CPython's own test suite (Lib/test), run under pon | being brought up (conformance-full-floor.json) fuzz | differential fuzzing vs CPython; must stay at zero divergences | — ft-stress | no-GIL/threading stress in the default runtime | — ゲートはscripts/gate.shです。その出力のみがゲートクレームとしてカウントされます。 bash scripts/gate.sh fast # build + workspace tests + conformance floor + AoT floor + ft-stress bash scripts/gate.sh full # + cpython-full, bench, tier0-only diff, fuzz, package-manager E2E | Individual meters cargo run -q -p pon-conformance -- --suite cpython --check-floor cargo run -q -p pon-conformance -- --mode aot --suite cpython-aot-subset --check-floor cargo run -q -p pon-conformance -- --suite cpython --modules <file.py> # one module, differential cargo run -q -p pon-conformance -- --suite fuzz --seed 42 --count 200 --jobs 8 コーパスファイルは一度着陸すると不変です。新しいカバレッジは新しいモジュールであり、マニフェストに入る前にpython3.14に対してバイト単位で同一であることが検証されます。CPythonの問題である（ponの問題ではない）逸脱は、隠蔽されるのではなく、pon-conformance/divergence-ledger.tomlに記録されます。 パッケージマネージャー ponには、pubgrub解決と標準のpyproject.tomlに基づいたuvスタイルのパッケージマネージャーが含まれており、PyPIシンプルインデックス、wheels、sdists、編集可能インストール、VCS要件をターゲットとしています。そのrunコマンドは、直接スクリプトディスパッチと同じランタイムパスを実行し、管理されたインポートルートを追加します。これは活発に開発中であり、まだランタイムゲートには統合されていません。 pon init | add | remove | install | lock | run | list | freeze | show | download | check | cache | env ピン留めされたツールチェーン これらのピンはワークスペース全体で確定しており、Cargo.lock / rust-toolchain.tomlによって強制されます。安易にずらさないでください。 Component | Pin | Toolchain ---|---|--- Parser | ruff git tag 0.14.0, PythonVersion::PY314 Backend | all cranelift-* crates =0.133.1, lockstep JIT | is_pic=true AoT | is_pic=true Reference | CPython v3.14.0, pinned in pon-conformance/vendor/cpython-3.14/REVISION ステータス 今日検証されていること（全てラチェットされ、CIでチェックされたフロアの後ろ）： pon runとpon buildはエンドツーエンドで動作します。クイックスタートはスモークテスト済みの例です。 JIT下でCPython 3.14とバイト単位で同一の209の差分コーパスモジュール。そのうち172モジュールはAoTコンパイルでもパスします。 パフォーマンス基盤が整っています：バックグラウンドコンパイル、OSR、インラインキャッシュ、型フィードバック。 まだ完了していないこと — これがアクティブなロードマップであり、順序通りです： CPythonテストスイート（cpython-full）：継続的な取り組み。失敗は波ごとにクラスター化され、解消されます。 標準ライブラリの構築：_io/os、math/struct/random、collections/itertools/json、datetime、importlibの互換性 — それぞれがネイティブモジュールと差分コーパスモジュールとして着陸します。 パフォーマンスラチェット：タグ付き小整数フリップ、TLABアロケーション、辞書高速パス、浮動小数点アンボクシング、呼び出し/属性特殊化、ジェネレータティアリング — ≥5倍CPythonジオメトリック平均ターゲット（数値 ≥20倍）に向けて。 AoT互換性の成長はフルコーパスに向けて、そして単一バイナリ製品の洗練。 No-GIL/フリースレッドランタイムの強化：スレッド/GC/シグナルストレスはデフォルトランタイムパス上にあり、残りのギャップはラチェットされたスイートによって追跡されます。 言語レベルでの既知のギャップは、上記のラチェットされたフロアを通じて解消されます — コミットされたフロアファイルが、このREADMEではなく、権威ある互換性ベースラインです。