Python删了自己的JIT：只快8%，却背不动这个包袱！！

2024年 Python 3.13 发布的时候，社区里很多人兴奋了一阵：CPython 终于要上 JIT 了，以前要靠 PyPy 才能拿到的加速，是不是终于能原生用上了？

两年过去，答案揭晓：10月19日，JIT 的作者正式撤回了 PEP 836，这个在主干里跑了三个版本（3.13、3.14、3.15）的实验性 JIT，即将从 CPython 主干中被移除。

不是 JIT 技术不行，是 Python 这个项目已经大到不敢随便"加东西"了。

故事要从2024年说起。Python 3.13 把一个实验性 JIT 合进了主干，当时的预期是：经过几个版本的打磨，它会变成一个正式受支持的特性。

接下来的 3.14、3.15 两个版本里，维护者确实做了大量工作：重写了 tracing 前端、加了寄存器分配、引入了 LLVM 21 作为构建依赖。

但到了2026年6月，Python 指导委员会踩了刹车：在没有一个正式 PEP 明确回答维护承诺、跨平台一致性、成功指标之前，JIT 不能继续留在主干。

讨论了四个月，作者在10月19日选择撤回 PEP 836。三年实验，正式落幕。7-8%的加速，配不上这个代价

为什么撤？最直接的原因是收益和代价不对等。

官方在 x86-64 Linux 上测出来的几何平均加速是 7-8%。这个数字什么概念？对一个跑在生产环境的 Web 服务来说，你几乎感知不到。对比一下：PyPy 在纯计算场景下能做到 3-50 倍加速——那才叫真快。

但维护这个 JIT 的代价是实打实的：要重写 tracing 前端、要做寄存器分配、要引入 LLVM 21 这个重量级构建依赖、每个版本都要追踪它和解释器主逻辑的语义差异。

为了一个 7-8% 的加速，让整个 CPython 仓库背上这些东西，指导委员会算完账觉得不值。

看 LWN 和 HN 的讨论就会发现，指导委员会不是反 JIT，他们担心的是 CPython 作为一个"受支持的产品"，不能变成一个什么都能试的沙盒。具体三个担忧：

平台一致性。Python 对用户的承诺是：同一份代码在 macOS、Windows、Linux、x86、ARM 上行为一致。JIT 在 x86-64 Linux 上测出来 7-8%，但其他平台呢？要不要为每个平台都做 JIT？做不到的话，"同一份代码同一种行为"这个承诺就破了。

内存开销。JIT 要 profiling 数据、要缓存编译后的机器码。对跑在 Kubernetes 小容器里的服务来说，内存多吃 10% 就是真金白银的成本。

行为差异。同一份 Python 代码，开 JIT 和不开 JIT，调试器看到的栈帧、性能分析工具的采样、C 扩展的交互，全都可能不一样。这对整个 Python 生态是一个巨大的适配负担。

对写 Python 的人来说，这件事的直接影响几乎为零。你的代码不会因此变慢——7-8% 的加速本来你也感知不到。真要性能，还是老办法：热点路径上 PyPy、C 扩展、或者挪到 Rust。

但这件事的信号意义比实际影响大：一个已经成熟到全球几亿人在用的编程语言，开始拒绝把"实验性特性"混进主干。指导委员会的态度很明确：主干是受支持的产品，不是实验室。想做 JIT 这种激进实验，去 fork 里做，做成熟了再谈回来。

LWN 的评论说这是 Python 治理的关键时刻——JIT 不会因此死掉，它可能会作为一个独立 fork 继续发展，就像 PyPy 那样。但 CPython 自己，选择了一条更稳、更慢、但对几亿用户更负责的路。

对一个用了二十年 Python 的人来说，这个决定看着可惜，但想想要是自己公司的线上服务因为一个 JIT 的边界条件出了诡异 bug，大概也会投赞成票。

以上就是“Python删了自己的JIT：只快8%，却背不动这个包袱！”的详细内容，想要了解更多Python教程欢迎持续关注编程学习网。