Python 的实验性 JIT 将被移除

# Python 的实验性 JIT 将被移除 来源：https://lwn.net/SubscriberLink/1102102/0c00e4d550f25f8c/ ## \[LWN 订阅者专享内容\] > ### 欢迎访问 LWN\.net 以下订阅者专享内容由一位 LWN 订阅者向您开放。数千名订阅者依靠 LWN 获取 Linux 和自由软件社区的优质新闻。如果您喜欢本文，请考虑订阅 LWN (https://lwn.net/subscribe/)。感谢您访问 LWN\.net\! Python 的实验性即时编译器 \(JIT\) (https://docs.python.org/3.13/whatsnew/3.13.html#an-experimental-just-in-time-jit-compiler) 于 2024 年为 3\.13 版本 (https://www.python.org/downloads/release/python-3130/) 加入 CPython，如今即将退出。今年 6 月，Python 指导委员会宣布 (https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638)，暂停 CPython 主分支中的 JIT 开发，直到有一份获准的 Python 增强提案 (https://peps.python.org/pep-0001) \(PEP\)，解决维护、兼容性方面的担忧，并明确成功衡量标准和完成时间表。JIT 维护者为回应委员会的要求，编写了 PEP 836 (https://peps.python.org/pep-0836/) \(“JIT 轰鸣：通往 CPython 正式支持的 JIT 编译器之路”\)，但经过数月讨论后，他们撤回了这份 PEP。目前看来，这个曾经前景可期的项目已停止开发。 Brandt Bucher 于 2024 年初将 JIT 加入 CPython (https://github.com/python/cpython/pull/113465)。通常，如此重要的功能应当在委员会批准一份标准轨道 PEP (https://peps.python.org/pep-0001/#pep-types:~:text=A%20Standards%20Track%20PEP) 后才会合入。Bucher 曾在一次 Python 核心开发者冲刺活动中就 JIT 发表演讲 \(YouTube 视频 (https://www.youtube.com/watch?v=HxSHIpEQRjs)、幻灯片 (https://github.com/brandtbucher/brandtbucher/blob/master/2023/10/10/a_jit_compiler_for_cpython.pdf)\)，并宣布打算 (https://github.com/python/cpython/pull/113465#issuecomment-1911279536) 合入这项功能，但他并未编写或提交 PEP 来申请批准。当时同时担任 Python 3\.13 发布经理的指导委员会成员 Thomas Wouters 敦促他这样做 (https://github.com/python/cpython/pull/113465#issuecomment-1969415137)。 Bucher 和 Savannah Ostrowski 起草了 PEP 744 (https://peps.python.org/pep-0744/) \(“JIT 编译”\)，这是一份信息类 PEP (https://peps.python.org/pep-0001/#pep-types:~:text=An%20Informational%20PEP%20describes%20a%20Python%20design%20issue)，也就是说，它只是向 Python 社区提供信息，并不代表对推进某项功能或项目达成了正式共识。LWN 于 2024 年 4 月报道了 (https://lwn.net/Articles/970397/) 围绕 PEP 744 的讨论，随后又报道了 Bucher 在 PyCon US 2024 上关于 JIT 的演讲 (https://lwn.net/Articles/977855/)，以及他在 PyCon US 2025 上的后续演讲 (https://lwn.net/Articles/1029307/)。 #### 用 PEP 推进 JIT 的开发一直以 PEP 744 为依据，直到今年 6 月，委员会正式要求 JIT 维护者编写一份标准轨道 PEP。人们可能会像 Antoine Pitrou 那样发问 (https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638/2)：为什么委员会认为现在该发声，要求提交一份新的 PEP？Wouters 表示 (https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638/4)，这项要求并非由某个“单一事件触发”，而是委员会已经讨论这个问题一段时间了，并表示希望确保 JIT 的开发不会干扰其他项目。“一直有人在努力让 JIT 与插桩、调试和性能分析良好配合。此外，还有外部 JIT \(如 CinderX\)、与 JIT 相关的项目 \(如 Numba 和 PyTorch 的 compile\)，以及关于第 3 层 JIT 的讨论。”委员会等到 Python 3\.15 测试版发布后才提出要求，“以明确表明我们接受 3\.15 的现状”。 委员会要求这份 PEP 论证 JIT 为何应当“成为 CPython 中受到正式支持的非实验性组成部分：它提供的保证、维护承诺，以及对再分发者的影响”。委员会设定了六个月的期限，要求在此期间提交并通过这份 PEP；否则，委员会将要求从 CPython 主分支中移除 JIT 代码。 Bucher、Ostrowski 和 Ken Jin 起草了 PEP 836，并于 7 月 3 日将其发布到 Python 论坛 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010)，征求社区反馈。它引发了大量讨论，既有支持，也有批评。评论中的一个主要观点是，这份草案似乎应该拆成两份独立的 PEP，例如 Wouters 的这条评论 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/19) 和 Mark Shannon 的这条评论 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/28)。例如，Shannon 认为，这份 PEP 应当只讨论接受 JIT 开发成果所需达到的目标，而不应包含实现细节。此外，也有不少人要求补充信息。 Bucher 对拆成两份 PEP 的建议提出了一些异议 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/21)，Ostrowski 则为 PEP 现有的结构进行了辩护 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/22)。“如果像我们在 PEP 中那样列出目标，却无法同时分享计划以及我们深思熟虑过的所有内容，我会感到不安。在我看来，没有计划支撑的目标根本算不上目标。” 我们上次在 9 月关注这个话题时 (https://lwn.net/Articles/1090385/)，围绕这份 PEP 的讨论已经放缓，既没有承诺编写新的 PEP，委员会也没有发表正式声明。当时委员会最新的表态来自其 8 月 6 日会议纪要 (https://discuss.python.org/t/2026-08-06-python-steering-council-meeting-summary/108612)：委员会已与 PEP 作者会面，正在“讨论 PEP 的现状，以及它是否回答了指导委员会在要求提交 PEP 时提出的问题”。 #### 在主分支中开展实验 9 月 21 日，Wouters 发布了 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/53) 一份概述指导委员会立场的声明，Ostrowski 未参与其中 \(她目前是指导委员会成员，但由于也是这份 PEP 的共同作者，因此回避了讨论\)。声明表示，这份 PEP 确实回答了委员会要求中重点提出的所有问题，“不过，有些回答的说服力可能不如其他回答”。 委员会希望明确，它所寻求的并非 JIT 成为受支持功能应满足的标准，也不是判断 JIT 是否应被视为这样的功能。相反，委员会评估的是，JIT 是否应当继续作为一项实验留在 CPython 主分支中。 > 允许在主分支中开展实验所带来的部分问题，在于缺乏统一设计，以及实验改变行为和 API 接口时，核心开发者、软件包维护者和用户所面临的不确定性。 委员会表示，PEP 对支持计划和性能标准的描述不够具体，在其他多个方面也过于含糊或过于乐观。声明列出了一份包含十项内容的清单，委员会希望“看到这些内容在 PEP 中得到明确说明，或者至少经过讨论后被否决”。委员会的清单表达了从内存影响到安全性等多方面的担忧。例如，在平台平等性方面，委员会希望确保 JIT 的设计易于适配新平台。它希望得到保证：JIT 的设计不会绑定特定平台，也不会要求维护者掌握特定平台的知识。 委员会指出的另一个领域是对用户的影响。它表示，PEP 对启用 JIT 后用户可感知的差异“过于乐观”。在许多情况下，用户会依赖解释器设计中的特殊行为，“正如我们在其他 Python 实现中，甚至仅仅在不同 Python 大版本之间所看到的那样”，委员会希望明确这些差异将如何处理。它们是否会被视为缺陷？如果某种行为差异无法避免，又该如何处理？诸如此类。 委员会认为，安全性是“PEP 中关注不足的一个领域”；它建议应当与 Python 安全响应团队 (https://devguide.python.org/security/psrt/) 展开讨论，而且安全审查也应当成为获得正式支持地位的标准之一。 PEP 836 规定了一项兼容性审查 (https://peps.python.org/pep-0836/#compatibility-review) 里程碑，与 Python 3\.17 的首个候选发布版同步——预计在 2028 年 8 月的某个时候——届时将运行 PyPI 上热门软件包的测试套件，以检查 JIT 是否导致它们出错。委员会希望将这一时间大幅提前。“我们认为这实在太晚了，兼容性审查应当是一个持续进行的过程，并尽早启动。” 委员会还担忧，JIT 的设计决策是在“缺少最终负责 \[CPython\] 开发、维护和支持的更大开发者群体进行严格审查”的情况下作出的。委员会表示，总体而言，PEP 836 “基本回答了我们提出的问题”，没有遗漏，但它希望围绕这些话题展开更多讨论，以便“在被要求对这份 PEP 作出裁决之前，衡量社区的支持程度和共识”。 几天后，Jin 回复 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/55)，感谢委员会提供详尽的反馈，并表示团队将着手落实这些建议。 #### 撤回 看来，经过一番考虑，PEP 的作者决定不再继续争取委员会的批准。10 月 19 日，Ostrowski \(她也是 Python 3\.16 和 3\.17 的发布经理\) 宣布 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/57) 撤回这份 PEP： > 指导委员会为这种规模的提案设定高标准是合理的，而我们认为，自己没有足够的个人时间和精力来继续推进当前版本。我们依然相信 PEP 中概述的技术方向，包括自由线程支持和基于方法的前端，也仍然看好 JIT 在 CPython 中的潜力。我们会公开参考实现，并在已撤回的 PEP 中提供链接，让其他感兴趣的人能够探索并在此基础上继续开发。 Barry Scott 问道 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/59)，这是否意味着 JIT 的开发已停止。Brett Cannon 回复 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/61)，主仓库中的开发将停止，但是否在其他地方继续，将由社区决定。Dunc Graham 提出 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/62)，也许还有时间在委员会的截止日期之前提交另一份 PEP。Cannon 表示 (https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to-a-supported-jit-compiler-for-cpython/108010/63)，这种可能性不大，“因为所有积极推动 JIT 的人，要么是那份 PEP 的作者，要么是它的贡献者”。 随着 PEP 被撤回，JIT 很可能很快就会从 CPython 主分支中移除，以确保移除所引发的任何问题都能在 Python 3\.16 开发周期 (https://peps.python.org/pep-0826/) 的早期得到解决。目前尚不清楚，最初推动 JIT 开发的人是否还打算继续投入，还是只会将其留给其他人在社区有足够兴趣时接手。我已向 PEP 作者发送电子邮件询问详情，但尚未收到回复。 ---