PON — 一个用Rust实现的Python 3.14 JIT/AoT原生编译器与运行时，基于Cranelift后端、Ruff解析器与Green Tea GC，通过字节精确差分测试与CPython保持一致性。

一、项目背景与痛点

Python作为最流行的动态语言之一，长期受困于执行效率问题。CPython的全局解释器锁（GIL）和纯解释执行模式使得CPU密集型任务性能不佳，即便有C扩展和PyPy等替代方案，依然存在兼容性差、部署复杂、调试困难等问题。

现有解决方案的局限：

• CPython：稳定但慢，无法利用现代CPU的SIMD指令，线程并行受限。
• PyPy：JIT加速显著，但兼容CPython扩展（如NumPy）困难，内存占用高。
• Cython：需要手动类型声明，不能直接运行纯Python代码。
• Numba：仅针对数值计算，对通用Python支持有限。
• Nuitka：AoT编译，但编译速度慢，调试体验差。

PON的目标是从底层重新设计Python的实现：将Python 3.14的抽象语法树直接编译为机器码，同时保持与CPython的字节精确行为一致。它不是一个简单的翻译器，而是一个包含完整运行时、垃圾回收器、类型推断和优化通道的独立实现。

二、安装与快速上手

环境要求

• Rust工具链（nightly版本，因为使用了最新的语言特性）
• LLVM 18+（可选，用于调试符号）
• 支持x86-64或ARM64的Linux/macOS（Windows未测试）

安装步骤

bash

克隆仓库

git clone https://github.com/can1357/pon.git
cd pon

编译PON编译器（耗时约5-10分钟）

cargo build --release

安装到系统路径（可选）

cargo install --path .

运行第一个Python文件

创建一个测试文件 hello.py：
python
def fibonacci(n):
if n <= 1:
return n
return fibonacci(n-1) + fibonacci(n-2)

print(fibonacci(35))

使用PON编译并运行：
bash

JIT模式（直接执行）

pon run hello.py

AoT模式（编译为可执行文件）

pon build hello.py -o hello
./hello

与CPython对比性能

bash

计时对比

time python3 hello.py
time pon run hello.py

在测试中，PON对纯数值计算的加速比可达2-5倍，递归函数调用优化尤其明显。

三、核心架构与亮点

1. 双模式编译：JIT + AoT

PON同时支持即时编译（JIT）和提前编译（AoT），这是大多数Python工具不具备的特性。

• JIT模式：在运行时将热点函数（如循环、递归）编译为机器码，类似于PyPy但更激进——PON在程序启动时就会尝试编译整个模块，而不是等待热点检测。
• AoT模式：将整个Python程序静态编译为原生二进制，无需运行时依赖Python解释器。这适合嵌入式系统、微服务部署等场景。

2. Cranelift后端

PON使用Cranelift作为代码生成后端，而非LLVM。Cranelift是Rust生态中原生的编译器基础设施，优势包括：

• 编译速度快：比LLVM快一个数量级，适合JIT场景。
• Rust原生：内存安全，无C++的ABI问题。
• 可嵌入：作为库使用，不需要外部工具链。

Cranelift生成的代码质量虽略逊于LLVM -O2，但对于动态语言而言已经足够，且PON在编译过程中会进行额外的优化（如内联缓存、逃逸分析）。

3. Ruff解析器

Python的语法解析通常使用CPython自带的解析器或ast模块。PON采用了Ruff解析器——这是Ruff（一个极快的Python linter）使用的解析器，用Rust实现，速度比CPython的解析器快10倍以上。

这意味着PON的解析阶段几乎不消耗时间，整个编译流程的瓶颈在于代码生成和优化。

4. Green Tea GC：并发无停顿垃圾回收

PON实现了Green Tea GC，这是一个分代式、并发、低延迟的垃圾收集器。

• 分代：年轻代使用复制算法，老年代使用标记-整理。
• 并发：GC线程与业务线程并行运行，最大停顿时间低于1ms。
• 无锁：使用读取屏障和写入屏障，避免全局暂停。

对比CPython的引用计数+循环检测GC，Green Tea GC在多线程场景下表现更好，且不会因为引用循环导致内存泄漏。

5. 字节精确差分测试

这是PON最独特的亮点：PON的每个编译结果都会与CPython 3.14的输出进行字节级对比。

项目包含一个自动化测试框架，对Python标准库中的模块（如math、json、re等）进行随机测试：

• 生成随机输入
• 分别在CPython和PON上执行
• 比较标准输出、标准错误、退出码、甚至内存布局（通过地址空间随机化排除）
• 如果发现差异，自动生成最小化复现用例

这种测试策略确保了PON在行为上与CPython完全一致，不会出现“编译优化导致语义改变”的问题。目前PON已经通过了超过10万个随机测试用例。

6. 类型推断与优化

PON内置了一个轻量级的类型推断引擎，可以推断出变量和函数返回值的类型。基于类型信息，PON可以：

• 消除动态派发（例如将a + b直接编译为整数加法或浮点加法）
• 内联小型函数
• 自动向量化（使用SIMD指令处理列表运算）

例如：
python
def add(x, y):
return x + y

如果PON推断出x和y都是整数，它会直接生成add eax, ebx指令，而不是调用__add__方法。

四、适用场景

1. 计算密集型Python脚本

• 科学计算、数值模拟、图像处理（如使用PIL但不想引入NumPy）
• 对性能敏感但不想重写为C/C++的算法实现

2. 嵌入式与边缘设备

• AoT编译生成静态二进制，无运行时依赖，适合树莓派、OpenWrt等资源受限环境
• 启动时间极短（无需解析字节码）

3. 微服务与Serverless

• 将Python函数编译为原生可执行文件，容器镜像从数百MB缩小到几MB
• 冷启动时间从秒级降到毫秒级

4. 游戏脚本与工具链

• 需要高性能的Python脚本引擎（如游戏Mod系统）
• 可以作为嵌入式的脚本语言运行时（类似于LuaJIT）

五、同类项目对比

特性	PON	PyPy	Nuitka	Cython	Numba
兼容CPython	字节精确	大部分	完全	需类型声明	仅数值
编译模式	JIT+AoT	仅JIT	仅AoT	AoT	JIT
编译速度	极快（Cranelift）	中等	慢（LLVM）	中等	快
内存占用	低（Green Tea GC）	高	中等	低	中等
多线程支持	是（无GIL）	是（STM）	依赖CPython	依赖CPython	部分
部署难度	极低（单文件）	需运行时	需运行时	需编译	需运行时
成熟度	实验性	稳定	稳定	稳定	稳定

PON的优势：

• 唯一同时提供JIT和AoT且字节精确兼容CPython的项目
• 原生Rust实现，内存安全，无C++遗留问题
• 极致的编译速度（Cranelift）和启动速度
• 激进但不破坏语义的优化策略

当前限制：

• 尚不支持所有Python标准库（如asyncio、socket仍在开发中）
• 动态特性（如eval、exec、动态属性访问）性能提升有限
• 仅支持Python 3.14语法（新特性如模式匹配、异常组已支持）

六、未来展望

PON的路线图包括：

• 支持完整的Python标准库
• 集成C扩展兼容层（通过ctypes和cffi桥接）
• 基于ML的类型推断（使用机器学习预测类型分布）
• 分布式编译缓存

项目目前处于早期阶段（约3000行Rust代码），但已经展示了惊人的潜力。如果你对Python性能优化、编译器设计或Rust系统编程感兴趣，PON是一个值得关注和贡献的开源项目。

七、项目链接

GitHub仓库：https://github.com/can1357/pon