Python 3.14 编译为 Metal —— 无需解释器
Python 3.14 compiled to metal – no interpreter

原始链接: https://github.com/can1357/pon

**pon** 是一个基于 Rust 编写的实验性高性能 Python 3.14 运行时与编译器。它摒弃了传统的解释器和字节码模式,利用 **Ruff 解析器**将 Python 代码转换为统一的中间表示(IR),随后通过 **Cranelift** 将其编译为机器码。 该项目提供两种主要工作流程: * **JIT(即时编译):** 进程内分层编译,具备类型反馈、后台优化及栈上替换功能。 * **AoT(预先编译):** 将模块编译为独立的本地可执行文件。 内存由自定义的 **Green Tea 垃圾回收器**管理,运行时采用了精简的对象模型,消除了 CPython 引用计数带来的开销。 该项目的核心是与 CPython 3.14 保持**字节级差异的一致性合约**。开发过程严格遵循 CI 强制执行的“基准”文件,确保任何输出回归都会导致构建失败。尽管项目仍处于深度开发阶段,其目标是成为“Python 版的 V8”——一个具备内置包管理器和全面标准库支持、快速且单一的二进制运行时。目前的工作重点在于扩展标准库、优化性能以及实现与 CPython 测试套件的完全兼容。

一个旨在将 Python 3.14 编译为 Metal 的项目发布后,在 Hacker News 上引发了激烈争论。怀疑论者认为,该项目本质上只是 Python 的一个“凭感觉”生成的子集,无法与 CPython 对等,并称这是继以往尝试在标准解释器之外实现 Python 后又一次失败的尝试。他们认为,如果没有深厚的人类专业知识和架构监督,维护如此复杂的 AI 生成代码将是不可能的,最终只会导致“脆弱”的软件。 相反,支持者认为 AI 显著降低了构建自定义编译器的门槛,使得以前成本过高的细分用例成为可能。他们将此视为软件开发方式的潜在转变,即由 AI 来处理繁重的实现和维护工作。 此次讨论还涉及了 AI 编写项目所带来的更广泛影响,批评者呼吁在 Hacker News 等平台上加强对“AI 垃圾内容”的筛选。尽管有些人将其视为开发者工具领域开创性的演进,但另一些人依然确信,如果没有人类维护者长期、稳健的投入,这些项目注定会沦为被遗弃且无法维护的技术债务。
相关文章

原文

pon — Python, compiled to metal — no interpreter

pon is a JIT & AoT native compiler and runtime for Python 3.14, written in Rust. There is no interpreter and no bytecode: every module is parsed with the ruff parser, lowered to one shared IR, and compiled to machine code through Cranelift — either just-in-time inside the process (pon run) or ahead-of-time into a standalone native executable (pon build). Memory is managed by a Green Tea garbage collector instead of reference counting, and correctness is enforced by a byte-exact differential harness against CPython v3.14.0.

The end goal is the bun/v8 of Python: a runtime that passes the CPython test suite, runs a multi-tier JIT well past CPython, ships single-binary executables, and includes batteries (package manager, tooling) out of the box. The project is under heavy active development — see Status for what is true today versus where it is going.

# JIT: parse → IR → Cranelift → run, in-process
printf 'def add(a, b):\n    return a + b\n\nprint("hello, world")\nprint(add(2, 3))\n' > 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

Both paths print the same bytes CPython would. That property is not aspirational — it is the exit gate of the conformance suite (see Conformance).

pon run <file> [args]
pon build <file> -o <out> [--allow-dynamic] [--opt] [--target <triple>]
pon repl
pon -c 'print(40 + 2)'
pon - < script.py

pon workspace architecture

One IR, two backends, one runtime ABI. Every tier — baseline JIT, optimizing JIT, and AoT — lowers the same IR and calls the same pon_* helper functions:

source.py
   │ ruff parser (pinned 0.14.0, PythonVersion::PY314)
AST ──> PON IR (pon-ir, one IR for every tier)
   │
   ├── 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)

Object model: CPython's heap object layout minus the refcount header. Errors cross the ABI as NULL sentinels, not unwinding. Integers are arbitrary-precision (num-bigint behind PyLong); a tagged small-int fast path is landing in the typed tier.

Tiering: tier-0 compiles everything boxed with no type feedback and is the correctness baseline (PON_TIER0_ONLY=1 forces it). Runtime helpers feed FeedbackCell type profiles from the first execution; hot functions recompile on a background thread and running loops enter the optimized code via on-stack replacement.

GC: the Green Tea collector owns all Python objects. Tier-0 uses conservative stack scanning with a register-flush trampoline at safepoints; the typed tier upgrades to precise Cranelift user stack maps.

Crate Role
pon-ir ruff-based frontend: parse Python 3.14, lower to the shared PON IR
pon-codegen IR → Cranelift CLIF, shared by every backend and tier
pon-jit in-process compilation, tiering, inline caches, OSR, background compile
pon-aot cranelift-object backend: object files and linked native executables
pon-runtime object model, builtins, stdlib native modules, the pon_* helper ABI
pon-gc Green Tea garbage collector
pon-abi ABI types shared between codegen and runtime
pon the pon binary: run/build/repl entry points + package manager (index client, resolver, wheel/sdist install)
pon-conformance differential conformance suites, fuzzing, benchmarks, floor ratchets

All dependencies are declared once in the root Cargo.toml under [workspace.dependencies]; member crates only inherit (see AGENTS.md).

The correctness contract is differential: a corpus module passes only if pon produces byte-identical output to CPython v3.14.0 (TZ=UTC, PYTHONHASHSEED=0). Passing sets are ratcheted into committed floor files, and CI fails on any regression below the floor.

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

The standing gate is scripts/gate.sh; only its output counts as a gate claim:

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

Corpus files are immutable once landed: new coverage is a new module, verified byte-identical against python3.14 before it enters the manifest. Divergences that are CPython's problem (not pon's) are recorded in pon-conformance/divergence-ledger.toml rather than papered over.

pon includes a uv-style package manager built on pubgrub resolution and the standard pyproject.toml, targeting the PyPI simple index, wheels, sdists, editable installs, and VCS requirements. Its run command executes through the same runtime path as direct script dispatch while adding managed import roots. It is under active development and not yet integrated into the runtime gates.

pon init | add | remove | install | lock | run | list | freeze | show | download | check | cache | env

These pins are settled workspace-wide and enforced by Cargo.lock / rust-toolchain.toml; do not drift them casually.

Component Pin
Toolchain nightly-2026-04-29 (rust-toolchain.toml)
MSRV rust-version = "1.94.0", edition 2024
Parser ruff git tag 0.14.0, PythonVersion::PY314
Backend all cranelift-* crates =0.133.1, lockstep
Bignum num-bigint 0.4.6 behind PyLong
CLIF flags preserve_frame_pointers=true; is_pic=false JIT / is_pic=true AoT
Reference CPython v3.14.0, pinned in pon-conformance/vendor/cpython-3.14/REVISION

What is verified today (all behind ratcheted, CI-checked floors):

  • pon run and pon build work end to end; the quickstart above is a smoke-tested example.
  • 209 differential corpus modules byte-identical to CPython 3.14 under the JIT; 172 of them also pass compiled AoT.
  • The perf substrate is in place: background compilation, OSR, inline caches, type feedback.

What is explicitly not done yet — this is the active roadmap, in order:

  1. CPython test suite (cpython-full): the standing grind; failures are clustered and burned down per wave.
  2. Stdlib build-out: _io/os, math/struct/random, collections/itertools/json, datetime, importlib parity — each lands as a native module plus a differential corpus module.
  3. Performance ratchets: tagged small-int flip, TLAB allocation, dict fast paths, float unboxing, call/attribute specialization, generator tiering — toward the ≥5× CPython geomean target (numerics ≥20×).
  4. AoT parity growth toward the full corpus, plus single-binary product polish.
  5. No-GIL/free-threaded runtime hardening: thread/GC/signal stress is now on the default runtime path, with remaining gaps tracked by the ratcheted suites.

Known gaps at the language level are burned down through the ratcheted floors above — the committed floor files, not this README, are the authoritative compatibility baseline.

联系我们 contact @ memedata.com