CPython 太慢？用 Codon 把计算密集脚本编成本地机器码

说明：微信源页触发「环境异常 / 验证码」，无法直读原文。本文按题意（告别 Python 龟速、编译器百倍提速），并基于开源仓库 exaloop/codon、官方文档 docs.exaloop.io 与 Exaloop 2025/2026 公开博文做工程向改写；Star / 版本口径以撰写时 GitHub 为准（约 1.6 万 Star，v0.19.x 一带）。

写数值循环、蒙特卡洛、基因组管线时，最常见的对话是：「先用 Python 验证算法，再找人用 C++ 重写。」中间那一步往往比算法本身更耗人。Codon 走的是另一条路：用接近 CPython 的语法，做 AOT（ahead-of-time）静态编译，把整段程序落到 LLVM 机器码上，官方口径是单线程相对 CPython 典型 10～100×，性能常与 C/C++ 同级；再叠加原生多线程（无 GIL）和自研 NumPy，部分场景还能再抬一档。

它不是「再包一层解释器」，也不是 Nuitka 那种以 CPython API 兼容为先的打包器。选型前先把边界说清：动态特性、缺省库、I/O 瓶颈 都可能让你看不见百倍数字。

一、它到底是什么：编译器，不是更快的 CPython

Codon（GitHub：exaloop/codon，Apache-2.0）自称 high-performance, zero-overhead, extensible Python compiler。官方 FAQ 的自我定位很干脆：

2025 年起许可证从 BSL 切到 Apache-2.0，商业使用门槛大幅下降；同年起自带 Codon-native NumPy（用 Codon 自身实现、可走多线程/GPU，并带运算符融合等编译期优化）。NPBench 单线程公开数字：几何平均约 2.4×，峰值超过 900×——记住这是基准套件，不是你业务脚本的保底承诺。

边界：Codon 不是 drop-in 替换。大仓库常要改类型不稳定代码、补齐尚未实现的标准库函数；缺的可用 from python import 回退到 CPython，但那一段通常吃不到编译红利。

二、加速从哪来：类型检查 + CIR + LLVM，而不是「魔法装饰器」

粗粒度流水线可以画成：

流水线一览：Python 源码 → 解析与类型检查 → CIR 中间表示与优化 → LLVM IR / 机器码 → 本地可执行或扩展模块（见下图）。

要点有三：

1. 尽量消灭动态运行时：能在编译期定下来的类型与布局，就不在解释循环里反复查。

2. CIR（Codon IR）层做高级优化：尤其是 NumPy 表达式的融合、内存分配消除；复杂表达式还会用代价模型决定「融多少、留多少顺序求值」。

3. LLVM 负责向量化与目标机特化：相比手写一套 SIMD 内核，让编译器看到完整程序往往更省维护成本。

安装与最小命令（官方文档）：

/bin/bash -c "$(curl -fsSL https://exaloop.io/install.sh)"
# 按提示把 ~/.codon/bin 加入 PATH

codon run hello.py
codon run -release fib.py
codon build -release fib.py   # 产出本地可执行文件

局部嵌入现有工程：

pip install codon-jit

import codon

@codon.jit
def hot_loop(n: int) -> int:
    s = 0
    for i in range(n):
        s += i * i
    return s

官方安装页用 fib(40) 递归做演示（M1 MacBook Pro 测得，仅作量级参考）：

本机（Linux box，2026-09-22 CST）对 practice/fib_bench.py 的对照约：CPython ~10.7s / Codon -release ~0.37s（约 29×），与官方 M1 示意同量级。

社区实测提醒：忘记加 -release 时，可能仍挂到常规 NumPy/调试路径，加速与产物体积都会「看起来不对」。发布路径务必显式 -release。

三、三条该用 Codon 的主航道

1. 纯 Python 数值循环 / 递归 / 仿真内核

三重循环填数组、递归搜索、粒子模拟这类「解释器税」极高的代码，往往是单线程 10～100× 区间的主力客户。官方博文里 300³ 填值循环：CPython 约 3.5s，Codon 约 0.01s（约 300×，同属示意环境）。

2. 需要真·多线程的 NumPy / 科学计算

CPython 有 GIL；Codon 用 @par 等机制跑原生线程。示例量级（官方）：同段 NumPy 工作负载，多线程相对 CPython 可达约 7×（仍取决于核数与内存带宽）。

@par(num_threads=n)
for i in range(n):
    y[i] = np.ptp(np.exp(-x[i, :]) ** 2)

3. 可下沉 GPU 的内核（@gpu.kernel）

Mandelbrot 一类规则网格计算，可把 kernel 标到 GPU。这已经超出「让 Python 快一点」，更接近用 Python 语法写可编译的算子——前提是你的环境有可用 GPU 后端，并且数据类型/索引模式符合 Codon GPU 约束。

四、什么时候不该期待「百倍」

官方 FAQ 把泼冷水写得很清楚，建议原样放进团队选型清单：

另外：int 位宽、异常策略（-disable-exceptions）、-fast-math 都会改变语义。性能开关不是免费午餐，数值代码务必用同一套 golden case 回归。

五、落地清单：从 hello 到可发布产物

1. Linux/macOS 安装 CLI，Windows 走 WSL。

2. 先用 codon run your_script.py 看类型/兼容报错；报错信息通常比「静默变慢」更有用。

3. 确认行为一致后，加 -release，再视需要 codon build -release。

4. 大仓不要一口吃：热点函数用 @codon.jit，或打成 extension 被 CPython 主程序 import。

5. NumPy 路径确认走的是 Codon-native 实现（新版本默认方向），并用小 benchmark 对比 CPython+NumPy。

6. 大数组 Linux 环境可关注 transparent hugepage；布局尽量 C-contiguous。

配套最小复现见本页 practice/fib_bench.py：同一文件可分别用 python3 与 codon run -release 对比耗时。

六、和周边工具怎么站队

一句话：Codon 卖的是「Python 语法的编译型算力」；你若卖的是「零改动跑完公司遗留 Django」，它不是那把钥匙。

七、小结

• Codon = Python 风味的 AOT 编译器（LLVM），不是更快的解释器皮肤。
• 官方单线程量级 10～100×；NumPy 原生实现 + 融合/并行/GPU 是 2025 之后的主叙事。
• 必须用 -release、必须接受非 drop-in、必须用基准验证——否则「百倍」只存在于标题党。
• 适合计算内核与科学/仿真热点；不适合 I/O 壳子和强动态遗留仓。

仓库与文档：

• https://github.com/exaloop/codon
• https://docs.exaloop.io

（Star / 版本随时间变化，引用前请再核一次 Release。）