← 返回信息流
AI 资讯Hacker News·2 小时前

Python 3.14 将直接编译为机器码，无需解释器

原标题：Python 3.14 compiled to metal – no interpreter

速览

Python 3.14 计划引入一项突破性特性：将代码直接编译到硬件层（机器码），不再依赖传统的解释器执行。这意味着 Python 程序可以获得接近 C 语言的执行效率，尤其在计算密集型场景下可能带来显著加速。对于依赖 Python 进行 AI 和机器学习开发的用户来说，这有可能降低运行成本并提高模型推理速度。不过该功能尚在开发阶段，实际效果和兼容性有待正式发布后检验。

AI 深度解读

背景

Python 的执行效率一直是社区关注的焦点。传统 CPython 解释器依赖字节码和引用计数，性能存在天花板。近年来，JIT 编译（如 PyPy、LuaJIT）和 AoT 编译（如 Nuitka、Codon）持续迭代，但鲜有项目同时做到“原生自举、零解释器、通过 CPython 测试集”且保持单二进制分发。pon 项目正是瞄准这一空缺——它用 Rust 重写了 Python 3.14 的运行时，完全抛弃解释器和字节码，将 Python 源码直接编译为机器码，其开发者自诩为“Python 界的 Bun/V8”。该项目目前处于密集开发阶段，并在 Hacker News 上首发，引发了广泛关注。

核心内容

pon 是一个为 Python 3.14 设计的 JIT 与 AoT 原生编译器和运行时，全部用 Rust 实现。它没有解释器，也没有字节码：每个模块通过 Ruff 解析器（固定版本 0.14.0，PythonVersion::PY314）解析为 AST，然后降级到一种共享的中间表示（IR），最后通过 Cranelift 编译成机器码。编译方式分为两种：

  • JIT 模式（pon run）：在进程内即时编译并执行。
  • AoT 模式（pon build）：提前编译成独立的本机可执行文件。

内存管理采用 Green Tea 垃圾回收器，而不是 CPython 的引用计数。正确性通过字节精确的差分测试框架保证，与 CPython 3.14.0 的输出逐字节对比。

工作流程示例：

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   # JIT
cargo run -p pon -- build hello.py -o hello && ./hello  # AoT

两条路径都会输出与 CPython 完全相同的字节。

架构：统一 IR，双后端，同一运行时 ABI

源代码经过以下管线：

source.py
│ ruff parser (pinned 0.14.0, PythonVersion::PY314)
AST ──> PON IR (pon-ir, 所有层共用)
│
├── pon run: pon-codegen ──> cranelift-jit ──> 进程内本地代码
│   tier-0 基线（全部装箱）
│   tier-1 类型化：内联缓存、OSR、后台编译
│
└── pon build: pon-codegen ──> cranelift-object ──> 目标文件 ──> 链接可执行文件
│
pon-runtime（对象模型、内置函数、NULL 哨兵 pon_* ABI）
pon-gc（Green Tea 垃圾回收器）
  • 对象模型：复用 CPython 的堆对象布局，但移除了 refcount 头部。错误通过 NULL 哨兵跨 ABI 传递，而非 unwinding。
  • 整数：任意精度（基于 num-bigint，包装为 PyLong）；带标签的小整数快速路径将在类型化层落地。
  • 分层编译：
    • tier-0 基线：全部装箱，无类型反馈，作为正确性基线（通过 PON_TIER0_ONLY=1 强制使用）。
    • tier-1 类型化：运行时辅助函数向 FeedbackCell 反馈类型 profile；热点函数在后台线程重新编译，正在运行的循环通过 on-stack replacement（OSR）切换到优化代码。
  • 垃圾回收：Green Tea 收集器拥有所有 Python 对象。tier-0 使用保守的栈扫描（在安全点通过寄存器刷新蹦床）；类型化层升级为精确的 Cranelift 用户栈映射。

正确性：差分验证

pon 的正确性契约是差分验证：一个语料库模块只有在其输出与 CPython 3.14.0 字节完全一致时才算通过（环境变量 TZ=UTC、PYTHONHASHSEED=0）。通过集被锁定为提交基线文件，CI 会拒绝任何低于基线的回归。

验证门控命令：

bash scripts/gate.sh fast   # 构建 + workspace 测试 + 一致性地板 + AoT 地板 + ft-stress
bash scripts/gate.sh full   # + cpython-full、bench、tier0-only diff、fuzz、包管理器端到端

语料库文件一旦落地就不可修改：新增覆盖必须是一个新模块，在加入清单前与 python3.14 字节一致。如果分歧在于 CPython 自身问题（而非 pon 问题），则记录在 pon-conformance/divergence-ledger.toml 中，而不是掩盖。

包管理器

pon 包含一个 uv 风格的包管理器，基于 pubgrub 解析和标准 pyproject.toml，支持 PyPI 简单索引、wheel、sdist、editable 安装和 VCS 依赖。其 run 命令通过与脚本派发相同的运行时路径执行，同时添加托管导入根。该功能正在积极开发，尚未集成到运行时门控中。

支持的命令：pon init | add | remove | install | lock | run | list | freeze | show | download | check | cache | env。

当前状态

已验证（所有通过锁定且 CI 检查的基线）：

  • pon run 和 pon build 端到端工作；上述 quickstart 是冒烟测试示例。
  • 209 个差分语料库模块在 JIT 下与 CPython 3.14 字节一致；其中 172 个在 AoT 下也通过。
  • 性能基础设施已就位：后台编译、OSR、内联缓存、类型反馈。

明确未完成（活跃路线图，按顺序）：

  • CPython 测试集（cpython-full）：正在进行中，失败项按波次聚类并逐一消除。
  • 标准库构建：_io/os、math/struct/random、collections/itertools/json、datetime、importlib 等 —— 每个作为原生模块加差分语料库模块落地。
  • 性能优化：带标签小整数翻转、TLAB 分配、dict 快速路径、float 拆箱、调用/属性特化、生成器分层 —— 目标几何均值 ≥5× CPython（数值计算 ≥20×）。
  • AoT 覆盖增长到全语料库，加上单二进制产品打磨。
  • 无 GIL / 自由线程运行时加固：线程/GC/信号压力测试已纳入默认运行时路径，剩余缺口由锁定套件追踪。

语言层面的已知缺口通过上述锁定基线逐步消除 —— 基线文件（而非本 README）是权威兼容性基线。

关键要点

  • 零解释器、零字节码：pon 直接解析源码

相关推荐

查看原文 →github.com