Python3.14正式发布！性能提升有多大

Python 3.14 在这轮非官方基准测试里跑得最快，和 3.13 比起来大约快了 27%。跟老版本比有比较明显的进步，但在某些任务上，像 PyPy 这样的解释器依旧快好几倍，Rust 更是远远领先。跟老版本比有比较明显的进步，但在某些任务上，像 PyPy 这样的解释器依旧快好几倍，Rust 更是远远领先。

这次测试是工程师 Miguel 做的，他做之前就提醒过大家，基准测试容易被误读。Miguel 提醒过大家，基准测试容易被误读。 他把测试限定在纯 Python 代码上，刻意排除了用 C 实现的库或扩展，目的只是把解说器本身的表演放大看清楚。每个测试都会跑三遍然后取平均值。测试脚本和测试框架都开源在 GitHub，博客里有完整说明和数据。

测试矩阵有点复杂，但也有条理。比较对象包括 CPython 从 3.9 到 3.14 六个版本，加上 PyPy（3.11）、Node.js 24 和 Rust 1.90。解说器有三种模式可选：标准、JIT（CPython 3.13+ 支持）和自由线程（free-threading，亦即无 GIL，3.13+ 支持）。脚本有两个，一个是递归计算斐波那契的 fibo.py（取第 40 项），另一个是对 1 万个随机数做冒泡排序的 bubble.py。线程模式分单线程和四线程并发，测试在两台机器上跑，一台是 Ubuntu 的 Intel Core i5 笔记本，另一台是 macOS 的 Apple M2 笔记本。Miguel 还把两个 Python 脚本移植成了 JavaScript 和 Rust，用来作为跨生态的表演参考。

关于两个测试脚本的选择也说清楚了。fibo 用典型的递归实现，计算第 40 个数在他的机器上需要几秒钟，适合看递归和函数调用的开销。bubble 则用迭代和大量循环，1 万个随机数能让排序在几秒内完成，侧重考察循环与数组操作的效能。两段代码并不是最快的实现，目标是用同一套代码在不同解说器上做对比。

单线程 fibo 测试显示，3.14 对比 3.13 有明显提升，算下来 3.13 的速度大约只到 3.14 的 79%。把 Linux 和 macOS 的数据平均后，差距比较稳。PyPy 在这项测试上表现惊艳，略快于 Node.js，速度几乎是 CPython 3.14 的 5 倍。可别忘了 Miguel 的提醒：由于没有用任何 C 实现的模块，这些数字更像是在放大解释器本身在纯 Python 工作负载下的差异。

把解说器的变体单独拿出来看也有意思。JIT 是 3.13 后引入的即时编译尝试，但在执行递归-heavy 的 fibo 时，JIT 没带来显著好处。Miguel 反复检查了构建，确认的确 启用了 JIT，就结论上怀疑 JIT 对这种高度递归的代码并不友善。自由线程模式在单线程测试里反而慢一点，在 3.14 中大致是标准模式的 91%，但这个差距比以前小了。

冒泡排序的单线程结果和斐波那契有些差别。3.14 依然是 CPython 家族里最快的，但领先幅度更小。3.11 在这项测试上大致能达到 3.14 的 91%，有意思的是 3.12 和 3.13 在这套排序测试里表现反而不如 3.11，Miguel 在去年的测试里也见过这个现象。PyPy 在冒泡排序上的表演更夸张：是 3.14 的 18 倍，甚至比 Node.js 快大约 3 倍。平台差异也能看到，macOS 在这个排序测试上比 Linux 略快，但各版本之间的相对比例差不多。

多线程的结果重点是给无 GIL 的解说器一个展示的机会。多线程 fibo 的做法是起四个线程，每个线程算 fibo(40)，计时从第一个线程启动到最后一个线程结束。单线程时 Miguel 的 Mac 单次 fibo 大致 7 秒，但四线程同时跑时 Mac 整体耗时约 25 秒，Linux 大致 32 秒，几乎是单线程的 4 倍左右，这正体现出 GIL 在阻碍并行 CPU 密集型 Python 代码。换到自由线程解说器后情况明显不同：在 3.13 中无 GIL 的解说器大致比标准模式快 2.2 倍，3.14 中这个提升达到了大约 3.1 倍，说明移除 GIL 对 CPU 密集的多线程场景的确 能带来显著加速。

多线程冒泡里每个线程拿到的是同一个随机数组的拷贝，四个线程并发各自排序。单线程情况下，3.14 的冒泡排序约需 2 秒；四线程并发时，Linux 总耗时约 10 秒，Mac 约 8 秒。自由线程模式在这项测试上表现不错，3.14 的 FT 比标准解说器快大约 2 倍，尤其在 macOS 上表现更优一些。JIT 在这类工作负载上的效果同样不稳定：在 Linux 上有小幅提升，但在 Mac 有时反而变慢。

整套测试里还有一些普遍要注意的点。Miguel 特别说明，他避免用 C 编写的扩展模块进入测试，缘由是这些模块跨版本差别一般不大，加入它们会把解说器的变化掩盖掉。现实世界的应用往往混合了 Python 与 C/C++/Rust 的模块，因此纯 Python 的基准只能作为参考点，而不能被当作决定性的结论。感兴趣的人可以在 GitHub 上查看完整脚本和基准框架，自己跑一遍会更直观。

顺带说两句我的感想：PyPy 的表演的确 让人想重点关注它，Free-threading 在多线程 CPU 密集任务上的提升也很值得关注。JIT 的表演有点像早期的尝试，对某些模式有效，对另一些却不行，继续观察比较合适。更多细节可以在 Miguel 的博客找到，完整代码放在 GitHub 上。