Python 3.14 发布了。它有多快？
今天是2025年10月8日，Python 3.14正式发布次日。让我们重新运行基准测试，看看新版Python究竟有多快！
注：若您不关心结果表格图表，只想直接阅读结论，点击此处跳转至文末。
关于基准测试误导性的简短说明
是的，尽管我将分享本次基准测试结果，但仍需再次提醒——正如前文所述——此类通用基准测试其实意义有限。运行这些测试固然有趣，这也是我坚持的原因，但仅凭几个简单的脚本，根本无法准确描绘Python解释器这类复杂系统的性能特征。
我设计的测试仅运行纯Python代码，避免使用任何依赖项，特别是C语言编写的函数。除Python解释器本身外，原生代码在Python版本迭代中提升速度的可能性较低，因此我认为将其纳入基准测试毫无意义。但实际应用中常混合使用纯Python与原生代码(无论是C、C++还是Rust)，因此虽然我的测试脚本能很好地评估纯Python代码的性能，却不能代表我们日常使用的应用程序。
简而言之，请参考我的基准测试，但请将其视为众多数据点之一，而非Python性能的最终定论！
测试矩阵
以下是我使用的测试矩阵，包含五个维度：
- 6个Python版本，外加Pypy、Node.js和Rust的最新版本：
- 3种Python解释器
- 标准解释器
- 即时编译(JIT)：仅适用于 CPython 3.13+
- 自由线程(FT)：仅适用于 CPython 3.13+
- 2 个测试脚本
- 2种线程模式
- 单线程模式
- 4线程独立计算模式
- 2台测试设备
- 运行Ubuntu Linux 24.04的Framework笔记本(英特尔酷睿i5处理器)
- 运行macOS Sequoia的Mac笔记本(M2芯片)
您或许认为将Node.js和Rust纳入基准测试有些奇怪。确实如此，但我仍将两个Python测试程序移植到JavaScript和Rust环境，以便获取Python生态系统之外的参考数据，从而全面评估性能。
测试脚本
以下是 fibo.py 文件中的核心逻辑：
def fibo(n):
if n <= 1:
return n
else:
return fibo(n-1) + fibo(n-2)经过多次实验，我确定使用此函数计算第40个斐波那契数在我的两台笔记本电脑上耗时数秒，因此下文所有测试结果均基于此设定。
以下是 bubble.py 中的排序函数：
def bubble(arr):
n = len(arr)
for i in range(n):
for j in range(0, n-i-1):
if arr[j] > arr[j+1]:
arr[j], arr[j+1] = arr[j+1], arr[j]
return arr针对此脚本，我同样通过目测确定数组大小，确保运行耗时约数秒。最终采用包含10,000个随机生成的数字的列表。
请勿将这些视为优秀示例，因为它们并非如此。若追求极致运行速度，存在更高效的编码方式。但本测试目的并非追求函数速度，而是比较不同Python解释器对代码的执行表现。选择这两个函数主要是因为它们分别采用递归与非递归编程风格，使测试集涵盖两种不同的编码方式。
我构建的基准测试框架会对每个测试函数执行三次运行，并报告三次运行的平均耗时。完整的测试脚本及基准测试脚本已发布在GitHub仓库。
基准测试 #1：单线程斐波那契算法
现在来看首个测试。本次测试测量了执行fibo(40)所需时间(单位：秒)。如前所述，每个数据点均运行三次代码并取平均值。
数据以表格形式呈现如下：
| fibo 1 thread | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.9 | 15.21 | 13.81 | 0.45x |
| 3.10 | 16.24 | 14.97 | 0.42x |
| 3.11 | 9.11 | 9.23 | 0.71x |
| 3.12 | 8.01 | 8.54 | 0.78x |
| 3.13 | 8.26 | 8.24 | 0.79x |
| 3.14 | 6.59 | 6.39 | — |
| Pypy 3.11 | 1.39 | 1.24 | 4.93x |
| Node 24 | 1.38 | 1.28 | 4.88x |
| Rust 1.90 | 0.08 | 0.10 | 69.82x |
最右侧列显示相对于3.14版本的速度比值，因此该列数值小于1表示对应测试比3.14慢，大于1则表示更快。计算这些比值时，我采用了Linux与macOS结果的平均值。
有时通过图表呈现数据更直观，以下是基于上述数值绘制的图表：
这些结果能说明什么？我们看到3.14相较3.13实现了显著的速度提升。其运行速度快了近27%，换言之3.13的运行速度仅为3.14的79%。这些结果还表明，3.11版本是Python从“非常慢”转向“不算太慢”的分水岭。
另有一点与Python 3.14无关：Pypy的表现依然令人惊叹。本次测试中它比Node.js快了些许，且比3.14快近5倍。令人印象深刻，但仍远不及Rust——正如预期，Rust的表现碾压所有竞争者。
即时编译与自由线程版本
从Python 3.13开始，CPython解释器提供三种版本：标准版、自由线程版(FT)和即时编译版(JIT)。自由线程解释器禁用了全局解释器锁(GIL)，这一变革有望在多线程应用中释放巨大性能提升。即时解释器内置了运行时编译器，可将代码即时编译为本机代码——理论上，这能通过仅需一次编译就加速多次执行的代码段。
前文分享的3.13与3.14版本测试结果均采用标准解释器，但我也想具体观察另外两种解释器变体如何处理我的测试。下表及图表展示了三种解释器在3.13和3.14版本下运行相同测试的对比结果：
| fibo 1 thread | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.13 | 8.26 | 8.24 | 0.79x |
| 3.13 JIT | 8.26 | 8.28 | 0.78x |
| 3.13 FT | 12.40 | 12.40 | 0.52x |
| 3.14 | 6.59 | 6.39 | — |
| 3.14 JIT | 6.59 | 6.37 | 1.00x |
| 3.14 FT | 7.05 | 7.27 | 0.91x |
结果略显失望。至少在此测试中，JIT解释器并未带来显著性能提升，甚至让我反复确认是否启用了该功能并正确构建了解释器。虽然我不太了解新JIT编译器的内部机制，但怀疑它可能无法处理这种高度递归的函数。
关于自由线程模式，去年我已发现解释器在单线程运行时效率低下。在3.14版本中，该解释器仍比标准解释器慢，但差距显著缩小——自由线程模式下运行速度仅为标准解释器的91%。
基准测试#2：单线程冒泡排序
以下是针对包含10,000个随机数的数组进行冒泡排序的基准测试结果：
| bubble 1 thread | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.9 | 3.77 | 3.29 | 0.60x |
| 3.10 | 4.01 | 3.38 | 0.57x |
| 3.11 | 2.48 | 2.15 | 0.91x |
| 3.12 | 2.69 | 2.46 | 0.82x |
| 3.13 | 2.82 | 2.61 | 0.78x |
| 3.14 | 2.18 | 2.05 | — |
| Pypy 3.11 | 0.10 | 0.14 | 18.14x |
| Node 24 | 0.43 | 0.21 | 6.64x |
| Rust 1.90 | 0.04 | 0.07 | 36.15x |
本次测试显示我的Linux和macOS笔记本存在较大差异，但每台机器上各版本的性能比值基本一致。差异仅表明Mac版Python能略微更快地运行此测试。
与斐波那契测试结果一致，3.14解释器仍是CPython中最快的版本，但本次差距较前次缩小——Python 3.11的运行速度仅为3.14的91%。值得注意的是，3.12和3.13版本的运行速度反而低于3.11，这种现象与去年基准测试中的异常结果如出一辙。
本次PyPy的运行速度达到3.14版本的18倍，甚至比Node快3倍。我必须花时间深入评估PyPy，其表现实在令人惊叹。
即时编译与自由线程版本
让我们看看3.13和3.14的专用解释器在冒泡排序测试中的表现。以下是结果表格和图表：
| bubble 1 thread | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.13 | 2.82 | 2.61 | 0.78x |
| 3.13 JIT | 2.59 | 2.44 | 0.84x |
| 3.13 FT | 4.13 | 3.75 | 0.54x |
| 3.14 | 2.18 | 2.05 | — |
| 3.14 JIT | 2.03 | 2.32 | 0.97x |
| 3.14 FT | 2.66 | 2.28 | 0.86x |
JIT解释器在此测试中略快，但仅限于Linux版Python。在Mac平台上，3.13版本稍快，而3.14则稍慢。速度差异非常微小，因此我认为JIT解释器仍需时间成熟。我使用的代码似乎无法充分受益于JIT编译。
自由线程解释器的运行速度同样较慢，但3.14版本的差距远小于3.13，这与两个基准测试结果一致。目前看来，常规工作负载下切换至自由线程解释器尚无实际意义，但当GIL严重阻碍性能时(仅限于需要大量CPU资源的多线程场景)，它可能成为值得考虑的选项。
基准测试 #3：斐波那契多线程版
今年我决定引入两个测试程序的多线程版本，主要目的是为自由线程解释器创造施展空间。
我为多线程斐波那契测试所做的，是启动四个线程分别计算第40个斐波那契数。这四个线程相互独立运行，而我使用的两台笔记本电脑均拥有超过四个核心，因此理应能很好地并行化此测试。我采用的时间测量方式是从启动首个线程到所有四个线程结束的总耗时。
以下是标准解释器下 fibo.py 以4线程运行的结果：
| fibo 4 threads | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.9 | 67.87 | 57.51 | 0.46x |
| 3.10 | 72.42 | 61.57 | 0.43x |
| 3.11 | 45.83 | 36.98 | 0.70x |
| 3.12 | 36.22 | 34.13 | 0.82x |
| 3.13 | 37.20 | 33.53 | 0.81x |
| 3.14 | 32.60 | 24.96 | — |
| Pypy 3.11 | 7.49 | 6.84 | 4.02x |
需说明的是，此处未运行Node和Rust版本的测试，因该测试仅针对Python的GIL机制。
当然这些结果本身信息有限。我们再次发现Mac似乎比Linux机器稍快，但除此之外各项指标基本呈线性扩展。例如单线程斐波那契测试耗时7秒，而多线程测试在Mac上耗时25秒，在Linux上耗时32秒——相差约4倍。这符合预期，因为GIL限制了Python代码的并行化能力。
现在来看Python 3.13和3.14解释器的详细结果：
| fibo 4 threads | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.13 | 37.20 | 33.53 | 0.81x |
| 3.13 JIT | 37.48 | 33.36 | 0.81x |
| 3.13 FT | 21.14 | 15.47 | 1.57x |
| 3.14 | 32.60 | 24.96 | — |
| 3.14 JIT | 32.58 | 24.90 | 1.00x |
| 3.14 FT | 10.80 | 7.81 | 3.09x |
这结果相当不错！
由于我们本就不期待JIT解释器在此测试中表现突出，可忽略其结果。但自由线程解释器向我们展示了移除GIL如何助力运行多个CPU密集型线程。
在Python 3.13中，自由线程解释器比标准解释器快约2.2倍。在3.14中性能提升约3.1倍。这是令人振奋的结果！
基准测试 #4：多线程冒泡排序
为完成本次基准测试，下方展示了四线程冒泡排序的测试结果。本次测试中，每个线程需对10,000个随机数进行排序，四线程均接收相同随机数组的副本。
首先观察标准解释器的表现：
| bubble 4 threads | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.9 | 16.14 | 12.58 | 0.66x |
| 3.10 | 16.12 | 12.95 | 0.65x |
| 3.11 | 11.43 | 7.89 | 0.97x |
| 3.12 | 11.39 | 9.01 | 0.92x |
| 3.13 | 11.54 | 9.78 | 0.88x |
| 3.14 | 10.55 | 8.27 | — |
| Pypy 3.11 | 0.54 | 0.59 | 16.65x |
这些结果同样不出所料。单线程版本在3.14版本中耗时约2秒，而本次测试中Linux系统耗时10秒，Mac系统耗时8秒。值得注意的是，Linux机器的耗时略高于单线程耗时的4倍。
以下是3.13和3.14版本中新型解释器的测试结果：
| bubble 4 threads | Linux | macOS | vs. 3.14 |
|---|---|---|---|
| 3.13 | 11.54 | 9.78 | 0.88x |
| 3.13 JIT | 10.90 | 9.19 | 0.94x |
| 3.13 FT | 9.83 | 5.05 | 1.17x |
| 3.14 | 10.55 | 8.27 | — |
| 3.14 JIT | 10.03 | 9.26 | 0.98x |
| 3.14 FT | 6.23 | 3.02 | 2.03x |
此处再次印证了自由线程解释器的适用场景。本次测试中Mac的自由线程表现优于Linux，但总体而言3.14 FT版本运行速度约为标准3.14版本的两倍。若您拥有CPU密集型多线程应用程序，切换至自由线程解释器或许是明智之选。
单线程冒泡排序测试中出现的JIT解释器在3.14版Mac解释器上运行更慢的异常现象在此再次出现，这表明该现象并非偶然。不过在我看来，这种差异尚不足以构成实质影响。我们只能期待JIT解释器在未来版本中持续优化。
结论
希望我的基准测试结果能引起您的兴趣。现将测试结论总结如下：
- CPython 3.14 似乎是所有 CPython 版本中最快的。
- 若暂时无法升级至 3.14，建议选用 3.11 之后的版本，这些版本比 3.10 及更早版本快得多。
- 3.14的JIT解释器似乎并未带来显著速度提升，至少在我的测试脚本中未见成效。
- 对于CPU密集型多线程应用，3.14的自由线程解释器比标准解释器更快，若您的应用符合此场景，值得尝试。但不建议在其他工作负载中使用该解释器，因其对未直接受GIL影响的代码仍存在性能劣势。
- Pypy的速度简直快得离谱！
您是否对Python 3.14进行过基准测试？若您的测试结果与我的不同，欢迎在评论区分享。
PyPy堪称史上最奇葩的项目之一。
居然真能用 🤣
当时这可是开创性研究，RPython基于当时最新的Python 2.7版本。2010年前后由此发表了大量论文。
天啊
看看GraalVM吧，它源自MaximeVM和JikesRVM这类研究项目，理念相近。
哦对！我之前没联想到这点，架构确实相似——否则要在同个引擎里即时编译多种语言简直难如登天。
依然很慢。Python功能丰富，但速度从来不是核心追求。
不过性能优化是近期才推进的。Lua证明解释型语言也能很快，只是此前未被列为优先事项。部分原因在于低效代码可轻松用C语言模块实现。
呃，这并非 仅 是优先级问题。Python极强的动态特性本质上导致许多优化难以实现甚至不可能，除非你愿意承受语言重大破坏性变更的代价。我认为他们从v2到v3的艰难历程中已领悟到——大多数人无法接受这种代价。
别误会，人们努力提升Python速度是好事，但我认为它永远无法与那些为性能而生的语言抗衡——毕竟Python背负着庞大的历史遗留代码包袱。
作为最爱Python且主要用Python工作的开发者(同时具备多种语言实战经验)，我如此评价。
JavaScript当初也是如此，最终还是变快了。
Python最近引入了即时编译器(JIT)，目前效果有限，但随着时间推移，它能通过忽略语言赋予的灵活性而专注于实际执行行为来优化代码。
JIT会通过追踪分析识别实际使用模式，针对性编译优化代码，并设置屏障确保假设成立。若假设被打破，它会回退慢速代码并重新推导。
JavaScript变快是因为谷歌投入巨资，通过顶尖工程团队打造了高效的V8引擎。除非某家巨头企业决定对Python进行类似投资，且获得社区支持使其得以实施，否则Python实现同等提升的可能性很低(即便理论可行，不同语言的性能瓶颈往往无法完全对应，Python的问题可能更难解决——但未经投入就无法确定)。
比如微软雇佣GVR和整个团队，专门致力于提升Python速度？
多家巨头曾尝试加速Python：谷歌有Unladen Swallow，Dropbox有Pyston，Meta有Cinder，微软有Faster CPython。据我所知，如今仅存Cinder。
因为真正的瓶颈并不出现在Python代码中
那为什么numpy不用Python编写？
好吧，你完全误解了我的意思…
正因为 numpy不是用Python写的，瓶颈才不会出现在Python代码中。因为你只是在粘合库调用。粘合代码不会成为瓶颈，真正耗时的部分在库内部
Instagram运行在Django上
数据库是用C语言写的
他们投入了时间和资金，但我从未觉得能与V8的投入相提并论。
这简直是史上最不幸的案例！
整个团队今年被 __ 解雇 __ 了，而且方式极其恶劣。
是的，我知晓此事。
我想强调的是，巨头企业本就在普遍赞助这类活动。看看Ruby圈和Shopify的现状，就能预见未来趋势。
就是那次。最近讨论3.14版本发布时我没能找到相关记录。希望微软最近的裁员潮没对他们造成太大冲击。
四个月前就取消了。
https://www.linkedin.com/posts/mdboom_its-been-a-tough-couple-of-days-microsofts-activity-7328583333536268289 -p4Lp/
不，上帝！求求您，不要！不要！……不要！不要啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊
我并非这个意思。Python基金会自己就声明过，提升Python性能是他们的当务之急。这在各类会议上都是高频议题。为此已推出多项举措：移除全局解释器锁(GIL)、添加即时编译(JIT)功能，以及自Python 3.11以来实施的诸多其他性能相关系统变更。
JavaScript的情况完全相同。而JavaScript确实变快了——这正是JIT编译的核心价值所在。
这篇文章本身就反驳了你的观点，因为PyPy版本的速度已与Node版本持平。
持有这种观点的人通常从未接触过Smalltalk、SELF、Common Lisp这类语言，它们同样具备动态特性，且拥有完善的编译工具链。
Smalltalk和SELF的研究成果，最终催生了Java和JavaScript的首批JIT实现。
在Smalltalk基于映像的模型中(Lisp语言采用类似方法)，任何内容都可在调试器中断后重置步骤时即时变更。
同样地，这些语言也具备Python的特性——能在运行时即时修改已编译代码，甚至无需进入调试器。
我并非否认语言无法加速，而是认为在不破坏广泛使用的库中细微细节的前提下实现加速并不现实。若语言设计之初就具备支持此类操作的API，情况或许不同，但Python并非如此。
若未来能实现重大改进，必是某家巨头企业决定像谷歌投入JavaScript那样倾力投入Python，而这将是历时数年、艰难跋涉却收益有限的艰巨任务。我并非说理论上不可能，但若能对语言进行破坏性变更，实现起来会容易得多。然而这将导致无人使用该语言。
另一个问题在于：若你如此重视性能，转用Go或其他更高性能的语言，再将Python作为粘合剂使用，几乎肯定能获得更高的性价比。
未必如此
看看/r/MATLAB这类语言，它与Python属于同级别，同样具有动态特性。多年前引入即时编译(JIT)后，性能提升立竿见影——突然间你可以编写简单的循环，JIT就能以媲美精心向量化代码的速度运行，此外在动态扩展列表等场景中也实现了诸多性能优化。
https://blogs.mathworks.com/loren/2016/02/12/run-code-faster-with-the-new-matlab-execution-engine/
当你将Matlab与/r/octave——这个兼容的开源实现方案进行比较时，这种优势同样显而易见(没错，我知道Octave也在开发自己的即时编译器)
现实中Matlab并不像Python那样极具动态性。影响速度的因素99%都与双精度数值相关——无论是单个双精度数值、双精度向量还是双精度矩阵。JIT技术(早在2002年就已推出！)带来了巨大效益，因为解释型Matlab在标量代码处理上极其缓慢。如今虽然仍显迟缓，但对于MATLAB适用的场景已足够用。不过处理标量时，它仍比直接用C++编写的代码慢一两个数量级。
连官方Test1示例都证明了这点：JIT版本每秒仅能处理2300万次赋值，而简单的C++循环每秒可达10亿次以上。
MATLAB的动态特性其实毫不逊色，我不会认为它比Python“更简单”(它具备类、运算符重载等特性，因此简单的
c = a + b语句在两种运行时环境中都非同小可)。更何况MATLAB语法会导致某些操作含糊不清，例如M(x)既可表示函数调用也可表示数组索引，方法调用语法既可写成obj.func()也可写成func(obj)，此类例子不胜枚举。需要澄清的是，我并非指代处理数值矩阵的典型场景(MATLAB本就擅长此道)，其对应方案是Python+Numpy组合承担相同角色——此时两者本质上都是为原生代码实现的线性代数库(BLAS、LAPACK等)提供封装。
我关注的是两者作为解释型动态语言的特性，以及如何通过完善的即时编译(JIT)大幅提升性能。
MATLAB代码的瓶颈通常源于函数调用的开销。典型的MATLAB代码往往采用向量化处理以减少方法调用——类似SIMD(单指令多数据)的机制，通过单次调用即可处理整个数据向量。
因此，
Test1示例的性能问题本质上源于紧循环中数百万次对foo1和foo2的函数调用，而非赋值操作本身。正如结果所示，启用“新”JIT后端后，它能识别热点并即时优化这些调用。公平地说，这篇博文已发布十年之久，所示基准测试数据并非最新，而JIT技术在此后持续改进。
我想强调的是，Python同样能实现高效编程——语言的“过度动态性”并非不可逾越的障碍。
请召唤Mike Pall，我们的LuaJIT弹药告罄，而他可是唯一的子弹制造商
确实如此。Python要实现高速运行仍非常困难，毕竟它可能是最动态的语言之一。反观PHP——本质上只是C语言的轻量封装——几十年来始终极其缓慢(直到最近才获得些许性能提升)；再看JavaScript同样高度动态，但有数十亿级企业持续投入资金进行极限优化。
[已删除]
笑死，我的小逻辑教授，你低估了C和C++的相似程度。不仅是关键词/语法层面能写出双平台通编的程序，生成的代码更是完全相同。
此外，我写这段可不是给网红在直播里念的。这是Python基金会的公开目标。从Python 3.11开始，他们就致力于提升Python性能，所以才热衷于移除GIL并实现JIT。
他们这么做是因为：
一件事叫聪明，另一件事叫蠢。
[已删除]
关键不在基础特性，而在语言规范的核心原则是否一致。直至C23近期更新前，C++本质上始终是C的超集。你误将C++标准库视为底层代码复杂度的提升，实则这些库与C语言特性无关。但事实并非如此。它们与C代码完全兼容。
https://stackoverflow.com/questions/2744181/how-to-call-c-function-from-c
这并非因为C++拥有特殊沙箱机制，将C调用转换为C++代码可识别的形式。根本原因在于C++本质上是同一门语言，只是增加了处理类的扩展功能——这正是C++最初被称为“带类的C”的缘由。这也解释了为何Bjarne Stroustrup常提及他与Dennis Ritchie的深厚友谊，并致力于在可能时保持两者代码库的兼容性——这种互操作性不仅具有务实价值，更承载着他个人情感的羁绊。
直到C99标准，C++才真正脱离C的超集范畴——仅凭新增的restrict关键字就足以证明其独立价值。
我认为注重性能的开发者本就不会使用CPython
遗憾的是这根本不成立。人人都爱这么说，但人人也爱用Python当万事万物的中间人。
比如你用GDB还是LLDB调试C/C++代码？恭喜，调试器显示变量的速度完全取决于CPython的性能——因为可视化脚本就运行在它之上。
遗憾的是我正在开发的项目确实如此
https://store.steampowered.com/app/3122220/Mr_Figs/
四年前的选择实在不妥。
如今回望，我会选择Defold(游戏引擎)或用C#/Haxe自行开发
对于像你这样的基础2D游戏(无需大量动画或实时图形处理)，Python绝对够用。不过若想转换代码，肯定存在相关库甚至能利用LLM实现——只是不确定是否值得投入精力。
确实基本没问题。但有个实时回放功能会疯狂吞噬所有可用的CPU资源。等pygame支持pypy后我打算尽快迁移，届时性能应该会更理想
速度是相对的。很多时候只要达到不成为瓶颈的程度就够了。
重写代码风险高且耗时，更换语言更是如此。
即使存在更快的方案，性能提升依然有价值。
大量现有代码运行在CPython上，性能优化可能意味着更长的生命周期、支持低端硬件等等
对蛞蝓而言，乌龟确实显得“快得离谱！”。而猎豹(C++)的概念则荒谬得多——快上几个数量级。
当然，但你需要有个参照标准，而“我们仅有的”无非是四种主要语言类型(我知道还有混合类型)：解释型语言、编译为字节码的语言(通常都带垃圾回收机制)、编译为机器码且带垃圾回收的语言，以及编译为机器码且不带垃圾回收的语言(如C、Rust这类手动内存管理的语言)。
我知道这过于简化，但你明白大意。
放松点
等等，PyPy怎么可能这么快！？
特化JIT编译器。
执行Python时最大的开销在于：每次操作前都需先解析操作语义。
例如
a = b + c实际执行流程如下：_ b是动态类型对象(PyObject _)
_ 从整数类型对象中加载 _add* 方法指针。
_ 执行 _add* 方法，该方法执行：
_ 若c非整数，则从c加载类型对象，并从中加载其 _int* 方法
而我仍忽略了许多细节，例如：
所有这些操作都在运行时完成。虽然效率较低，但具备高度灵活性。
而PyPy的做法类似于：
通常该方法的参数都是整数类型。
倘若编译一个特殊版本，在调用时先检查参数是否均为整数类型，若满足则跳过运行时的类型检查直接执行加法运算。
若出现异常情况(如溢出或错误)，则回退到慢速解释版本。
事实证明，程序中绝大多数时间都消耗在少量特定函数上，且这些函数通常接收相同类型的参数。因此这种方法能显著节省时间。
以上是极度简化的说明，PyPy实现该效果的实际方法相当独特。本质上PyPy甚至不是真正的JIT编译器，而是一种算法——它以解释器为输入，从中生成JIT编译器，再运行于Python解释器之上形成最终产物。
此说法有误，整数加法不存在隐式转换。
实际流程是：先尝试调用
b的__add__方法，若返回NotImplemented，则转而调用c的__radd__方法。(如你所述)你说得对，我记错了讨论规则。
无论如何，关键在于它必须在运行时为每次加法操作都重新推导这些规则。
没错，今年欧洲Python大会上就有PyPy维护者做过相关演讲，详细阐述了这个机制。
正因如此，即便是即时编译器也存在性能上限，因为某些检查环节仍不可或缺。
Luke Gorrie(u/lukego)曾发布过关于(lua/raptor)jit特化的精彩视频(现已设为非公开)
https://www.youtube.com/watch?v=Kds7TUnWOvY
附注：学生时代看过他的视频，如今我从事AI工作而他效力于Anthropic，颇有意思
JIT
一个全面完善的版本。
我该出发了。
这个版本蕴含无限可能。
尽管有人会说全是空中楼阁。
既然PyPy如此高效，为何用户迟迟不将其确立为事实标准？是否存在兼容性问题？
确实，它与C扩展库兼容性不足——这在Python库生态中占据重要地位。它也曾落后于Python主分支，不过如今情况已大不相同。
我的意思是3.11版本相当陈旧，确切说是三年之久。我好奇的是：虽然每个版本通常都有大量cpython变更和少量标准库更新，但核心语言本身变化不大。那么为何会落后整整三年？这给人的感觉就是长期缺乏维护——无论是否属实。
我是PyPy维护者。首先，我们团队不足五人，而CPython拥有数十位贡献者。其次，每个版本都会对解释器进行大量内部改动，这些都需要从C语言转译为Python。第三，标准库的变更往往涉及C语言扩展，同样需要转译为Python。例如3.12版本对f字符串解析进行了深度改动，新增了调试类型和装饰器的语法支持等。所有这些都需要投入大量工作，回报却并不高。
感谢您出色的工作。希望PyPy能获得更多支持。我曾多次尝试使用它，但对于我的数据科学用例，使用CPython搭配Numba效果更好。不过我为其中一个公共库制作了PyPy轮子，虽然不确定是否有人使用。
感谢您的见解。非常欣赏您的工作，尤其能体会到您常做那些回报甚微的工作的感受。
感谢你辛勤而常被忽视的付出！
你如何看待CPython团队在JIT性能提升方面为何远逊于PyPy？
显然PyPy更成熟，但即便如此…CPython的JIT进展仍极其缓慢。他们是在为未来爆发式进展打基础，还是注定要经历长达数年的缓慢推进？
PyPy约在2003年开始探索即时编译技术，直到7年后的2010年才步入正轨。掌握即时编译的实现方法需要相当长时间，后续的启发式算法调优更是耗时费力 (可以说PyPy从未完成这部分工作。Antonio Cunio近期在CPython核心开发者冲刺会议的演讲中[https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-world–cpython-core-dev-sprint/%5D提及重写了部分复杂模块) (https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-world–cpython-core-dev-sprint/)
为何CPython维护者不与你们合作？PyPy能为纯Python代码带来惊人加速，理应成为Python默认实现
PyPy源于欧洲，而CPython历来以美国为基地。此外，CPython在漫长发展历程中始终将简洁性置于性能之上——尽管这种理念近期有所转变。安东尼奥·库尼近期参加了CPython开发者冲刺活动https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-world–cpython-core-dev-sprint/，而新推出的Py-Ni项目正是基于HPy的诸多理念构建。基于Python的CPython REPL则源自PyPy。
PyPy在标准库和语言规范方面自然遵循CPython规范。而CPython的许多变更确实考虑了PyPy的特性：例如制定了“所有基于C的标准库模块都应提供纯Python版本”的政策。但两者的解释器架构差异巨大，因此难以直接移植代码。
感谢说明。
感谢分享，特别是关于f字符串的见解。我确实记得这个变更(似乎是允许递归字符串等功能？)，但完全忘记了具体细节。
三年不算久
这意味着三次免费性能升级的机会，以及一些精妙的特性。其中两次(因为3.14刚发布)大多数用户可能已经享受过了。若要更换解释器，他们就得放弃这些优势。
它只能运行纯Python代码，因此任何用C或其他编译语言编写的库都无法在PyPy上运行。虽然存在其他兼容性问题，但这是最关键的障碍。
此外PyPy更新周期较慢，导致其代码始终滞后于标准版本。
即时编译机制还存在优化瓶颈：需多次运行代码才能完成优化编译。因此仅执行一两次的小脚本在PyPy上反而比标准Python运行更慢。
目前标准Python正在引入JIT技术，但需确保兼容性不被破坏，因此实现这一目标尚需时日。
PyPy虽可使用CPython的C语言API，但效率较低——每次从Python切换到C语言时，传递的对象都需在C语言中重新创建并同步。而JIT无法解析C代码内部逻辑。在多数数据应用场景中，Python本身并非性能瓶颈。大部分处理时间消耗在NumPy、PyTorch或pandas中——这些库都借助C/C++完成核心计算。
这很合理。我不确定是否有人在运行完全不依赖C或Fortran调用的Python程序。
我认为情况已经不同了？虽然很久没用过，但他们声称支持C语言扩展——可能并非完全支持，而且速度较慢： https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy
这绝对是错误的！
https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy
等3.141版本吧，会更精准。
这次发布本该叫Pithon才对
πthon
滚动条得拉太远了。
我们是否一致同意将版本命名为pithon？
若未达成共识，能否这样命名？
那我们得改用TeX风格的版本编号了。
快如圆周率 🙂
Pi thon
终于迎来Pithon时代。
非理性地快
为何MacOS比Linux快？我感到被冒犯了。
测试并未追求硬件等效性，因此系统间比较并非重点。
测试使用了两台不同笔记本
系统调用几乎不存在。性能理应相同。
对我而言更关键的问题是“能否快速实现解决方案”。90%的情况下，开发速度远比执行速度重要得多。
当执行速度至关重要时，请改用其他语言，用C语言编写核心循环，或调整算法(添加函数缓存等)。
请展示因编程语言而非代码本身成为瓶颈的实例
虽然任何语言都可能写出低效代码，但并非所有语言都能轻松实现高效代码。
那就在0里写慢代码吧。
鉴于Python的运行效率，当n值较大时，几乎所有非简单的算法都会触发此问题。数组库numpy之类工具仅作为编译代码封装层就存在合理性。
我们公司经常发现，将Python服务简单迁移到Go服务后，性能和密度(相同请求量下所需服务器更少)都会显著提升。事实证明，当操作次数足够多时，差异就会累积起来。
哇，这太疯狂了。
任何需要多线程处理的CPU密集型代码。但这并非唯一问题，多数时候症结在于内存分配与释放、关键服务启动缓慢等。
人们可能不知道，从底层原理看内存速度其实在变慢(访问时间与时钟周期之比)，而非变快。
但编写缓存友好型代码并非主流教学内容，在所有数据都用字典表示的语言里这几乎不可能实现。
显然没接触过支撑数十亿用户规模的服务架构的人。
我指的是…Instagram是用Python写的。(但必须澄清：楼主观点依然错误。)
不知你从何得出此结论。我在Meta工作，整个组织几乎所有后端基础设施都基于HHVM或C++。
我是在Instagram项目中得出的结论。Instagram底层采用Python的Django框架，虽与蓝色服务器存在关联，但绝大部分代码(包括大量使用Bloks的前端代码)都是用Python编写的。
Import-CSV myFile.csv任何实质性改进都得靠C#实现，因为PowerShell太慢了。
荒谬的论断配上荒谬的示例。
再多的简单高效业务逻辑，叠加起来照样会引发延迟问题。反序列化/序列化更是巨大痛点。构建涉及海量数据交互的复杂程序时，需选择能最大限度降低自身内存/CPU开销的语言/平台。遗憾的是，Python在老旧单体项目中扩展性欠佳。
当热循环、繁重序列化和线程竞争成为瓶颈时，语言本身就是瓶颈；Python在这三方面都表现出色。真实案例：30-40k rps的JSON API-json + Pydantic占用>60% CPU。切换至orjson和msgspec后CPU消耗减半，随后将验证移至小型Rust pyo3模块解决了尾部延迟问题； 跨服务通信中 gRPC/Protobuf 胜过 REST/JSON。数据处理采用 Polars + Arrow 规避 Python 循环；共享内存多进程比线程更高效处理并行。基于 FastAPI 和 gRPC，我还用 DreamFactory 快速生成数据库支持的 API，无需手写序列化器。关键在于隔离热点路径并更换运行时环境，而非仅调整代码结构。
你把所有东西都切换到Rust了还说语言不是问题？
真有意思：这个帖子刚开始有20个赞，后来就沉底了😂
你要多少例子？我能给你成千上万个。若用Python重写这些代码，语言本身就会成为瓶颈：
https://github.com/torvalds/linux
https://github.com/pytorch/pytorch
https://github.com/mozilla-firefox/firefox
https://github.com/mooman219/fontdue
说真的
任何能在GPU上完成的任务；并非所有语言都能高效运行(甚至根本无法运行)。
我在研究中编写树搜索算法，转用C++能提升数个数量级的运行速度(这就是我的做法)
用Python解析NeTEx的欧盟交通信息XML文件相当慢。但它是少数能提供足够好XSD生成库的语言之一，能处理NeTEx极其复杂的XSD。
当然——https://programming-language-benchmarks.vercel.app/
等等 https://benchmarksgame-team.pages.debian.net/benchmarksgame/
汽车中的ABS和ESC系统。
以下是几个未经优化的单线程#8程序，采用逐行直译方式转换为不同编程语言的版本。
π-thon
难道错过了将其命名为Pithon的机会？
曾考虑添加
pithon可执行文件，但因长期维护负担而被否决。但据我所知，本次发布专为这个目的推出了
πthon没有，我这里只有这些：
idle3, idle3.14, pip, pip3, pip3.14, pydoc3, pydoc3.14, python, python3, python3-config, python3.14, python3.14-config不过你可以自己创建符号链接。
哎呀 ;(
看来这个在某个时候被撤销/放弃了。
其实没有。似乎仍在：https://github.com/python/cpython/blob/3.14/Lib/venv/__init__.py#L319
在我这里运行正常：
在正式发布版本中同样有效：
我猜我之前没成功是因为只看了uv给的命令。
是啊，我直接执行“uv venv”也没成功。
所以…是PiThon？
这明明是Python最不该推广的东西，可我看到的几乎全是它
Pi-thon