这是关于 Python 中 JIT 编译（即时编译）的 PEP（Python 增强提案）的详细内容总结：

• 作者与讨论：作者为 Brandt Bucher 和 Savannah Ostrowski，讨论地址为Discourse thread，状态为草案，类型为信息性，创建于 2024 年 4 月 11 日，适用于 Python 3.13 版本。

• 内容概要：

  • 摘要：今年初，实验性“即时”编译器被合并到 CPython 的main开发分支，此添加是对 CPython 传统执行 Python 代码方式的重大改变，值得广泛讨论。该 PEP 旨在总结此添加背后的设计决策、实现的当前状态以及使 JIT 成为 CPython 永久非实验部分的未来计划，鼓励读者参考相关资源了解更多。
  • 动机：CPython 一直通过将 Python 代码编译为字节码并在运行时解释来执行代码，Python 3.11 后使用“专门化自适应解释器”，3.12 后从 C 语言域特定语言生成该解释器，虽有性能提升但仍有瓶颈，最明显的策略是静态编译优化后的轨迹以避免解释带来的开销。
  • 原理：开发和维护优化编译器非常复杂昂贵，使用现有编译器框架虽可简化任务但会引入运行时依赖和更高的 JIT 编译开销，而 copy-and-patch 可从生成解释器的同一 DSL 生成高质量模板 JIT 编译器，且无运行时依赖、维护负担低。
  • 规格：JIT 目前不是默认构建配置的一部分，在满足一定条件（如对至少一个流行平台提供有意义的性能提升等）之前为实验性，应避免在生产中使用，一旦非实验性，应与其他构建选项类似对待，支持多个平台但某些平台可能永远不会获得 JIT 支持。
  • 向后兼容性：由于当前解释器和 JIT 后端都由相同规范生成，Python 代码行为应保持不变，调试工具仍可正常工作，但 C 代码的调试器目前无法追溯 JIT 帧，此问题虽应修复但不是当前的高优先级。
  • 安全影响：JIT 在运行时会生成大量可执行数据，引入新的攻击面，但已采取最佳实践来减轻风险，如不暴露可写且可执行的数据等，作者不是安全专家但可与 Python 安全响应团队合作处理安全问题。
  • 如何教授：不同角色在 JIT 方面的情况不同，如 Python 程序员在非实验性阶段可能注意到性能和内存使用的变化，维护者在修改相关代码时需注意对 JIT 的影响等。
  • 参考实现：关键部分包括Tools/jit/README.md、Python/jit.c等文件。
  • 拒绝的想法：包括在 CPython 外部维护 JIT、默认启用 JIT、支持多个编译器工具链、编译基础解释器的字节码、添加 GPU 支持等，原因包括维护困难、性能提升不明显、增加测试和维护负担等。
  • 未解决的问题：包括速度（目前与现有专门化解释器速度相当，正在进行改进工作）、内存（比现有解释器使用更多内存，正在优化）、依赖（目前有构建时依赖 LLVM，讨论中）等问题。
• 脚注与版权：文档置于公共领域或 CC0-1.0-Universal 许可证下， whichever is more permissive。