Skip to main content

Chapter 26: Adaptive Runtime (PEP 659)

CPython 3.11 开始把一部分解释器性能优化放进运行时执行路径：同一段 bytecode 在冷启动时保持通用形态，在多次执行后根据对象类型、命名空间版本和调用形态改写为更窄的专用指令。读完本章后，读者应能追踪一个 Python 表达式从普通 opcode 到 adaptive opcode，再到 specialized opcode 的状态变化，并判断某段代码的性能收益来自哪一个 runtime 假设。

本章以 PEP 659 描述的 specializing adaptive interpreter 为主线。PEP 659 是 CPython adaptive runtime 的机制模型；当前 CPython 版本中的 opcode 名称、源码文件组织和 dis 输出会继续演进。Python 官方 dis 文档也明确把 bytecode 标为 CPython implementation detail，并说明 3.11 起可以通过 show_caches=True 观察 inline cache，通过 adaptive=True 观察 adaptive bytecode。本文的结论限定在 CPython 3.11+ 的解释器模型内，PyPy、MicroPython 或其它实现可以采用不同策略。

贯穿本章的材料是一段属性读取、全局名字读取、函数调用和整数累加混合在一起的代码。它足够短，又能覆盖 adaptive runtime 最常优化的路径：LOAD_ATTR、LOAD_GLOBAL、CALL 和 BINARY_OP 一类指令。

class User:
    def __init__(self, name):
        self.name = name


def score(users):
    total = 0
    for user in users:
        total += len(user.name)
    return total

这段代码的语言语义很稳定：每次循环读取 user.name，调用内置 len，再把结果累加到 total。解释器优化的空间来自运行时事实：循环中的 user 多数时候是同一个类的实例，name 多数时候存在相同位置，len 多数时候来自 builtins，total 多数时候保持为整数。adaptive runtime 的工作是把这些稳定事实记录到指令附近，并在事实继续成立时走快路径。

26.1 Quickening and adaptive bytecode​

Quickening 是把普通 bytecode 改写成可继续自我调整的执行形态。普通 bytecode 来自编译阶段，表达的是 Python 语义，例如“读取属性”“读取全局名字”“执行调用”。adaptive bytecode 仍然表达同一份语义，但指令位置可以携带计数器和缓存槽，解释器可以根据执行中看到的对象状态把该位置替换成更专用的 opcode。

在 score 里，冷代码第一次进入执行时，解释器需要按通用规则处理 user.name。通用属性读取要考虑实例字典、类字典、descriptor、__getattribute__、MRO、异常路径和其它边界。循环运行多次后，如果解释器持续看到 user 是 User 实例，并且 name 可以从实例值存储中取得，属性读取指令就具备 quickening 的条件。此时解释器把该指令位置转成 adaptive 形态，后续再由 adaptive 形态尝试特殊化。

这个过程可以用三个状态理解：普通指令负责语义完整性，adaptive 指令负责收集与判断，specialized 指令负责在已验证假设下执行快路径。状态之间的变化发生在 code object 对应的执行数据上，对 Python 层可见语义保持一致。用户仍然写 user.name，异常仍然按属性访问规则抛出，调试和反汇编工具看到的细节则可能因参数和版本不同而变化。

图中的核心路径是“语义先稳定，执行形态再变窄”。编译器输出的 bytecode 不需要提前知道 users 里会放什么对象；运行时在执行过程中积累证据。证据达到阈值后，指令位置可以从通用路径转向专用路径。证据失效后，同一位置可以回到 adaptive 形态重新观察。

dis 在这一章只适合作为观察工具。dis.dis(score) 给出的是面向人阅读的 bytecode；dis.dis(score, adaptive=True, show_caches=True) 可以显示更多 adaptive 与 cache 细节。输出格式、opcode 名称和 cache 布局都受 CPython 版本影响，所以它能帮助确认当前解释器的行为，不能作为跨版本规范来写死。

quickening 的工程意义在于把优化成本推迟到热代码路径上。函数定义和模块加载时，解释器无需为每个潜在热点立即准备完整优化结构。只有当某个 code object 的某个指令位置执行多次，adaptive runtime 才为那个位置投入计数、缓存和替换成本。这个粒度比整函数优化更小，也让回退成本保持局部。

26.2 Specialization family and inline cache system​

Specialization family 是围绕一个通用操作建立的一组 opcode。一个 family 通常包含通用语义、adaptive 入口和若干 specialized 变体。以 LOAD_ATTR 为例，通用语义是“从对象上读取属性”；specialized 变体可以分别服务实例值数组、module 属性、slot 属性等更窄场景。不同 CPython 版本的具体 opcode 名称会变化，但 family 这个阅读模型稳定有效。

inline cache 是跟在指令附近的缓存空间，用来保存快路径需要的运行时证据。user.name 的快路径可能需要保存类型版本、属性位置、字典 keys 版本或其它校验字段。len 的全局名字读取可能需要保存 globals 和 builtins 的 keys 版本，以及目标对象在命名空间存储中的索引。cache 放在 bytecode 附近，解释器执行到该指令时可以直接读取这些字段，减少重复查找。

adaptive counter 决定何时尝试特殊化。一个 adaptive 指令执行若干次后，计数器触发 specialized helper 检查当前对象和环境是否适合某个变体。specialized 指令也维护自己的成功与失败信号。输入符合缓存里的假设时，计数器向稳定方向移动；输入偏离假设时，计数器向回退方向移动。计数器让解释器在“继续信任当前假设”和“重新观察”之间做局部决策。

score 里的 len(user.name) 可以拆成三个 family 视角。第一处是 LOAD_ATTR：它关注 user 的类型和 name 的取值路径。第二处是 LOAD_GLOBAL：它关注 len 来自 globals 还是 builtins，以及相关命名空间 keys 是否变化。第三处是 CALL：它关注 callable 的调用约定、参数数量和 vectorcall 入口。三个位置各自有独立缓存，某一处失败不会强制其它位置同步回退。

这个拆分解释了 adaptive runtime 的一个关键性质：优化对象是指令位置，而非整段源码文本。两处看起来相同的 obj.attr 可以形成不同缓存，因为它们在不同 code object、不同偏移、不同历史输入下执行。相同函数内的两次 len 调用也可能因为热度、命名空间变化和调用对象不同而处在不同状态。

内联缓存解决的是重复动态分发的成本。动态语言的开销经常来自“每次都重新确认同一件事”：这个对象属于什么类型、属性从哪里取、全局名字在哪个 namespace、调用对象走什么入口。cache 把上次确认过的结构性事实放到指令旁边；下一次先校验事实仍然成立，再直接取结果或进入窄路径。校验本身也有成本，所以只有热路径和类型稳定路径容易受益。

26.3 De-optimization and runtime patching​

De-optimization 是 specialized 指令在运行时假设失效后回到更通用执行形态的过程。PEP 659 选择单个 bytecode 级别的特殊化，使回退可以局限在当前指令位置。解释器无需把整段函数从优化版本还原成未优化版本，只要把当前 specialized opcode 替换回 adaptive opcode，或在本次执行中走通用 fallback 路径。

继续看 score。如果 users 里前一万次都是 User，后一项突然换成另一个类，user.name 的 specialized 属性读取需要先校验对象类型和相关版本。校验失败后，本次读取可以走通用属性访问路径，保证 descriptor、__getattribute__、异常等语义仍然完整。失败次数累积到阈值后，该指令位置降低对旧假设的信任，回到 adaptive 形态重新观察。

class Proxy:
    def __getattribute__(self, name):
        if name == "name":
            return "dynamic-name"
        return super().__getattribute__(name)

mixed_users = [User("Ada"), User("Guido"), Proxy()]

Proxy 的加入改变了属性读取的运行时路径。对 User 实例成立的“从固定实例存储读取 name”这一假设，无法直接覆盖自定义 __getattribute__ 的对象。adaptive runtime 的正确行为是先保护语义，再更新自身状态。性能优化永远附着在可验证假设上；假设失效时，解释器回到完整语义路径。

runtime patching 指解释器在执行过程中改写指令或相关缓存字段。这里的 patching 由解释器完成，Python 程序无需显式修改 bytecode。解释器在安全点更新当前 code object 的快速执行表示。调试、tracing、profiling 和反汇编展示会引入额外边界；PEP 659 的设计强调 quickened 形态与用户可见 bytecode 形态保持兼容关系，便于必要时回到原始语义观察。

De-optimization 的判断依据通常来自版本标签、类型匹配、cache 命中和计数器。命名空间 keys 变化会影响 LOAD_GLOBAL 的缓存信任；类型版本变化会影响属性和方法查找；调用目标变化会影响 call specialization；输入类型频繁交替会让 specialized 指令长期失败。失败代表当前输入偏离缓存假设，也是 adaptive runtime 识别“这个位置不适合当前 specialized 形态”的信号。

这个机制给源码阅读一个稳定顺序：先确认通用 opcode 的语言语义，再找该 opcode 所属 family，然后看 specialized 变体校验了哪些条件，最后看校验失败时是否走 fallback 或回到 adaptive。这样读源码时不会被 opcode 名称数量拖散，因为每个 specialized opcode 都是在回答同一个问题：它省掉了通用路径中的哪几步，又用哪些 guard 保证省略安全。

26.4 Performance boundary of adaptive runtime​

Adaptive runtime 优化的是解释器对热路径的重复确认成本。它擅长处理类型稳定、命名空间结构稳定、调用形态稳定的代码。score 的循环符合这个模型：同一条属性读取反复处理相同类的实例，同一条全局名字读取反复定位 builtins 中的 len，同一条累加指令反复处理整数。这样的代码会把动态语义中的一部分判断摊薄到 cache 校验上。

它的收益边界也来自同一个模型。输入类型频繁切换时，同一指令位置很难保持单一 specialized 形态。对象结构经常变化时，属性 cache 的版本校验会反复失败。代码只执行一次时，quickening 和特殊化没有足够热度。主要成本来自 I/O、网络、数据库、正则引擎、NumPy 内部 C 循环或其它外部系统时，Python opcode 快路径只能影响外围调度部分。

算法复杂度仍由程序结构决定。把一个嵌套循环从平方级改成线性级，通常比让内部某个属性读取特殊化更有决定性。大量创建临时对象、构造 traceback、频繁跨 Python/C 边界、在热循环里改变类或模块命名空间，这些成本可能覆盖 adaptive runtime 带来的局部收益。性能分析时应先定位时间消耗在哪个层级，再判断 specialization 是否处在主路径上。

内存开销也属于边界条件。inline cache 需要额外空间，计数器和缓存字段需要随 code object 的 quickened 形态存在。PEP 659 讨论过 3.10 opcache 与 3.11 inline cache 的内存比较，结论指向一种明确取舍：用可控内存换取热路径上的更短执行路径。工程判断要同时看运行时、内存、启动阶段和代码热度。

Adaptive runtime 不改变 Python 语言承诺。它不会让属性读取跳过语义上必须执行的 descriptor 规则，也不会让自定义 __getattribute__ 在需要触发时消失。它只在 guard 证明当前输入仍然匹配时采用专用路径。这个边界能解释很多“为什么没有明显加速”的案例：代码语义过于动态、热点不在 Python opcode、输入形态不稳定、或工作负载被外部系统主导。

因此，写 Python 代码时不应围绕某个当前版本的 specialized opcode 反向设计业务结构。更稳定的工程策略是让数据形态清晰、热循环内的对象结构稳定、全局名字少被动态改写、属性访问路径可预测、核心算法复杂度先达标。这样做即使跨版本也有价值；adaptive runtime 只是更容易从这些稳定结构中获得收益。

26.5 PEP 659 reading model​

阅读 PEP 659 时，应把它当成一套 runtime 判断模型，具体版本的 opcode 清单只作为观察材料。模型的四个关键词是 opcode、cache、counter 和 object type。opcode 表示当前位置的语义操作；cache 保存快路径需要的证据；counter 决定继续信任还是重新观察；object type 和相关版本标签提供 guard 的判断材料。

对 score 这样的函数，可以按固定顺序复盘。第一步，找热点指令位置：属性读取、全局名字读取、调用、二元运算。第二步，确认该指令属于哪个 specialization family。第三步，判断 cache 需要保存哪些事实，例如类型、dict keys 版本、属性 offset、callable 入口。第四步，列出哪些变化会让 guard 失败。第五步，把失败路径放回通用 Python 语义，确认结果仍然正确。

这个模型也适合读 CPython 源码。源码文件组织随版本变化，早期 PEP 资料会提到 Python/ceval.c 和 Python/specialize.c，较新的 CPython 还会出现 generated cases、bytecode definition 和生成文件。源码阅读时，稳定入口应放在一组问题上：“这个 opcode 的通用语义在哪里实现、family 变体在哪里定义、cache layout 在哪里声明、specialization helper 校验什么、失败时回到哪里”。

下面的检查顺序可以迁移到其它 adaptive opcode：

  • 先看语义 opcode：确认原始 Python 操作是什么，例如属性读取、全局名字读取、调用或二元运算。
  • 再看 family：确认该操作有哪些 adaptive 与 specialized 变体，理解每个变体服务的窄场景。
  • 再看 cache 字段：确认快路径依赖哪些运行时事实，例如类型版本、命名空间 keys 版本、索引或调用入口。
  • 再看 counter：确认成功和失败如何推动指令继续特殊化、保持现状或回到 adaptive。
  • 最后看 fallback：确认 guard 失败后如何回到完整语义路径，以及本次执行如何保持正确结果。

PEP 659 的价值在于把动态语言性能问题转成局部假设管理问题。传统描述会把 Python 慢归因于“动态”，这个说法过粗。adaptive runtime 给出的更精确表达是：某些指令位置需要反复执行类型检查、名字查找、属性解析和调用分发；当这些位置出现稳定运行时事实时，解释器可以把事实缓存到指令附近，并用 guard 把快路径和完整语义连接起来。

回到本章贯穿材料，score 的性能行为不应只看源码表面有几行。更可靠的读法是：循环让指令变热，稳定的 User 类型让 LOAD_ATTR 适合特殊化，稳定的 builtins len 让 LOAD_GLOBAL 适合缓存，稳定的调用形态让 CALL 具备快路径，稳定的整数累加让二元运算减少通用分发。任何一个位置的输入变得多态，对应位置就会降低 specialized 形态的收益。

最小自检任务​

阅读下面代码，判断 total += len(item.name) 这一行中哪些运行时事实有利于 adaptive runtime 形成 specialized 路径，哪些变化会削弱这些 specialized 路径的收益。无需运行 dis，只按本章模型分析。

class Item:
    def __init__(self, name):
        self.name = name


def total_length(items):
    total = 0
    for item in items:
        total += len(item.name)
    return total

答案要点​

item.name 对应属性读取指令位置。若 items 中大多数对象都是 Item 实例，且 name 存在稳定的实例存储路径，LOAD_ATTR family 可以用类型和属性位置作为 cache 证据。guard 命中后，解释器减少通用属性查找中的多层判断。

len 对应全局名字读取和调用。若函数所在 globals 没有覆盖 len，builtins 命名空间结构也稳定，LOAD_GLOBAL 可以缓存查找结果或相关索引。若调用目标持续是内置 len，参数数量稳定，CALL 相关路径也更容易保持窄形态。

total += ... 对应二元运算与局部变量更新。若 total 和 len(item.name) 都保持整数，二元运算可以减少通用 numeric dispatch 的成本。若某次 item.name 返回自定义对象，或 len 被 globals 覆盖成普通 Python 函数，或 items 混入大量自定义 __getattribute__ 的对象，对应 instruction cache 的 guard 会失败，解释器会走通用路径或回到 adaptive 形态重新观察。

结论是：adaptive runtime 的收益来自同一指令位置反复看到稳定对象类型、稳定命名空间结构和稳定调用形态。输入多态、命名空间频繁变化、对象属性路径动态化、热点转移到 I/O 或外部 C 扩展时，specialization 对总耗时的影响会下降。

本章知识点总结​

  • Quickening：Quickening 把普通 bytecode 转成可自我调整的执行形态，为后续 adaptive 与 specialized 指令提供位置。
  • Adaptive opcode：Adaptive opcode 在指令位置收集运行时证据，并按计数器触发特殊化尝试。
  • Specialized opcode：Specialized opcode 在 guard 成立时执行更窄的快路径，同时保留语义回退能力。
  • Family 模型：Specialization family 把一个通用操作拆成 adaptive 入口和多个窄场景变体。
  • Inline cache：Inline cache 把类型、命名空间版本、属性位置或调用入口等证据存放在指令附近。
  • Counter 决策：Counter 记录命中和失败趋势，决定保持 specialized 形态、重新观察或回退。
  • De-optimization：De-optimization 在假设失效后把局部指令位置带回 adaptive 或通用执行路径。
  • Runtime patching：Runtime patching 由解释器在执行过程中更新 opcode 或 cache 字段，Python 层语义保持一致。
  • 性能边界：Adaptive runtime 主要降低热路径上的重复查找、分发和校验成本，对算法复杂度和外部系统耗时影响有限。
  • 版本边界：Bytecode、cache 布局和 specialized opcode 名称属于 CPython implementation detail，跨版本阅读应抓住模型而非固定名称。
  • 阅读顺序：分析 adaptive 行为时先看语义 opcode，再看 family、cache、counter、guard 和 fallback。
  • 工程判断：稳定数据形态、稳定命名空间和稳定调用形态更容易让解释器从 adaptive runtime 中获得收益。