Python 3.15的JIT编译器开发重回正轨，已提前实现性能目标：在macOS AArch64上比解释器快11-12%，x86_64 Linux上快5-6%，性能提升幅度从20%减速到100%加速不等。虽然尚未支持自由线程，但团队计划在3.15/3.16版本实现。开发者坦言这一突破来之不易。

标题：Python 3.15的JIT重回正轨

核心内容： 1. 性能突破
CPython JIT已提前实现性能目标：在macOS AArch64上比尾调用解释器快11-12%，在x86_64 Linux上比标准解释器快5-6%。初步数据显示，性能提升范围从20%减速到100%加速不等（不含unpack_sequence微基准测试）。自由线程支持计划在3.15/3.16版本中实现。

2. 项目转折点

   • 早期困境：3.13和3.14版本的JIT曾因性能不佳（甚至慢于解释器）和主要赞助商撤资而前景不明。
   • 团队协作：核心贡献者（Savannah Ostrowski、Mark Shannon等）和社区开发者的共同努力是关键。通过拆分复杂任务、降低项目"巴士因子"（确保每个JIT阶段有至少2名维护者），团队规模从2人扩展到4名核心成员。

3. 技术优化与幸运突破

   • 追踪记录（Trace Recording）：Brandt提议的重写前端意外催生了"双分派"机制，将JIT代码覆盖率提升50%，最终实现性能反转。
   • 引用计数消除：基于Matt Page的字节码优化工作，团队通过消除分支显著提升效率，该优化也成为新人参与JIT开发的入门教程。

4. 基础设施与人文因素

   • Savannah的4台机器组成的"基础设施团队"提供了每日性能反馈；Mark和Diego分别负责架构设计和ARM适配。
   • 社区实践：通过细化任务指南、庆祝小胜利（如每个PR明确标注成果）吸引11名贡献者参与，将解释器指令转换为JIT友好格式。

5. 行业互助
   作者强调与PyPy开发者CF Bolz-Tereick的交流、以及编译器爱好者Max Bernstein的定期讨论对技术视野的拓展作用。

结语：
"JIT终于能飙起来了（JIT go brrr）"的成果印证了——人才与运气同样重要。技术细节可参阅优化方案原文。

（注：原文中涉及个人情感表述和部分技术细节轶事已精简，保留关键事件脉络与数据。）

以下是评论内容的总结：

1. 关于Python JIT编译器的进展

   • 主要观点：Python正在开发自由线程支持和JIT编译器，预计在3.15/3.16版本中实现。
   • 引用：
     • "We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track."
     • "The guy said he hopes the free-threaded build'll be the only one in '3.16 or 3.17'."

2. 关于PyPy的JIT编译器

   • 主要观点：有人质疑为何不直接使用PyPy已有的JIT编译器。
   • 引用：
     • "Doesn't PyPy already have a jit compiler? Why aren't we using that?"

3. 关于JIT实现细节的疑问

   • 主要观点：评论者希望了解JIT的高层设计和实现细节，如trace projection与recording的区别，以及refcount消除的具体实现。
   • 引用：
     • "Is there anywhere a high-level introduction/example of how trace projection vs recording work and differ?"
     • "Similarly, I don't entirely understand refcount elimination; I've seen the codegen difference..."

4. 关于Python JIT实现的困难

   • 主要观点：与其他语言（如Ruby、PHP、JS）相比，Python实现JIT的进展缓慢，引发疑问。
   • 引用：
     • "What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases?"

5. 关于图表和代码名称的困惑

   • 主要观点：评论者对图表中的代码名称（如blueberry、ripley等）表示困惑，难以区分JIT和CPython的对应关系。
   • 引用：
     • "Sorry but the graphs are completely unreadable. There are four code names for each of the lines."

6. 关于copy-and-patch策略的讨论

   • 主要观点：copy-and-patch策略是一种低复杂度、可增量实现的JIT设计选择，但优化空间有限，且自由线程支持是其难点。
   • 引用：
     • "Copy-and-patch compiles specialised bytecode 'templates' ahead of time and just patches in the runtime values."
     • "The free-threading interaction is the hard part they're still working through."