失业一年后，Python JIT 竟然提前跑通了
11% 的性能提升，提前一年交付。
这组数字放在任何科技项目里都不算惊艳，但如果我告诉你——做出这玩意的团队一年前刚被金主抛弃，工资断供，项目差点咽气——是不是就刺激多了？
这就是 Python 3.15 JIT 的真实剧本。没有霸道总裁接盘，没有硅谷巨头输血，一群志愿者在 Savannah 的衣柜里（字面意义）架起四台服务器，硬是把一个"比解释器还慢"的笑话，变成了"确实能跑"的奇迹。
先给不懂的朋友补个课：JIT 为啥这么难搞？
JIT，即时编译器，通俗说就是让 Python 边跑边把代码翻译成机器语言，理论上能快好几倍。听起来很美，现实很骨感。
8 个月前，CPython 的 JIT 是个灾难。 测出来比解释器还慢，社区骂声一片。更要命的是，Faster CPython 团队的主要赞助方在 2025 年撤资了。核心开发者们突然从领工资变成打白工，项目前途未卜。
作者自己都在博客里写："我当时真的在怀疑这项目还能不能搞出点正经速度提升。"
死马当活马医，他们决定把项目交给社区。说实话，这步棋风险极大——JIT 编译器向来是高手专属，门槛高到能吓退 99% 的开发者。
社区接盘：把"玄学"拆成"乐高"
他们干了件很聪明的事：降低巴士因子（bus factor）。
啥叫巴士因子？就是"多少人被巴士撞了项目就会瘫痪"的暗黑指标。以前 JIT 的中间优化层全靠 2 个人撑着，现在他们目标是在前端、中端、后端都保证有 2 个活跃维护者。
Brandt Bucher 先动手，把优化任务拆成" mega-issues"——比如"试着优化一条指令"。作者接棒，把解释器指令转换成对 JIT 更友好的形式，还写了超详细的操作指南。
结果？11 个人涌进来干活，把几乎整个解释器都翻新了一遍。
从 1% 提升到 3-4%，看起来不多，但这是社区力量的证明。
最离谱的转折：一个"误解"救了全场
接下来的剧情，连编剧都不敢这么写。
剑桥的 CPython 核心开发者聚会上，Brandt 提议把 JIT 前端改成追踪模式（tracing）。作者一开始反对，但出于"友好性质的赌气开发"（spite-driven-development），他决定重写一版，就为了证明这想法行不通。
三天搞出原型，慢得要死——比原来慢 6%。
眼看要放弃，一个美丽的误会发生了。Mark Shannon 建议搞双调度表（dual dispatch table），让追踪表存"正常指令的追踪版本"。但作者理解错了，搞了个更极端的方案：只留一个负责追踪的指令，第二调度表所有指令都指向它。
这他妈居然成了。
原来双表方案会让解释器体积翻倍，代码膨胀导致变慢。而"单指令双表"方案只增加一个指令，既保留了超快的基础解释器，又能追踪记录。作者管这叫"双调度"（dual dispatch），自称这是"小型艺术品"。
这个改动让 JIT 代码覆盖率暴增 50%。 换句话说，如果没有这个误会，后面所有优化效果都要打对折。
删代码比写代码更难：干掉引用计数
另一个神来之笔是引用计数消除（reference count elimination）。
Matt Page 之前在字节码优化器里做过相关工作，作者发现 JIT 生成的代码里，每个引用计数递减都带个分支判断。他随手一试："要不把这分支删了？"
结果爆炸。 单个分支看起来不贵，但 Python 每条指令都要来这么一下，累积起来就是天文数字。
更妙的是，这活儿特别适合新人练手。虽然是个手动重构的苦力活，但能让新人快速理解解释器和 JIT 的运作原理。这招成了 3.15 JIT 的主要优化方向，既提性能又培养人，一箭双雕。
衣柜里的服务器和沉默的英雄
说到基础设施，作者开了个玩笑："我们的基础设施团队是一个人，在 Savannah 的衣柜里跑了四台机器。"
Savannah Ostrowski 一个人扛起了整个 CI 和性能监控。每日自动跑分成了救命稻草， regressions（性能回退）能被立即抓住，优化效果实时可见。
Mark Shannon 技术过硬，但作者说他"已经被互联网夸太多了，我就不拍马屁了"。
Diego Russo 负责 ARM 硬件上的 JIT，还在搞 profiler 支持——作者说这难度"怎么强调都不为过"。
Brandt Bucher 奠定了机器码后端的基础，没他，新人就得去写汇编，那估计早把人吓跑了。
运气、人、和闭嘴写代码
作者最后总结得很实在：运气很重要，人很重要，JIT go brrr。
他没讲什么英雄主义的故事，反而承认成功是"对的时间、对的地点、对的人、对的赌注"。如果 Savannah、Mark、Diego、Brandt 这几个人缺了任何一个，这事都成不了。
他还特别感谢了 PyPy 的 CF Bolz-Tereick 和编译器圈子里的 Max Bernstein。"想法不是孤岛"——跟编译器大佬们吹牛，看 PyPy 的源码，让他成了更好的 JIT 开发者。
现在 Python 3.15 的 JIT 在 macOS AArch64 上比解释器快 11-12%，在 x86_64 Linux 上快 5-6%。自由多线程（free-threading）还没搞定，但目标已经定在 3.15/3.16。
说实话，这个成绩放在 JIT 编译器史上不算惊天动地。但考虑到他们是从"被金主抛弃、比解释器慢"的坑里爬出来的，这 11% 就格外有分量。
有时候，技术最大的敌人不是复杂度，而是绝望。
他们证明了，哪怕在最惨的时候——没钱、没资源、代码还跑不过解释器——只要别散伙，继续拆问题、继续聊、继续写，运气总会撞上来。
哪怕是以"误解"的形式。
【kimi-k2.5锐评】：开源项目的浪漫就在于，当资本抽身时，一群固执的技术宅能用"误解"和"衣柜服务器"把死马医成活马，顺便给整个行业上一课——人比代码难维护，但也比代码更扛造。
参考链接：
https://fidget-spinner.github.io/posts/jit-on-track.html
