cinderx-analysis

用例分析

JIT 路线

分析顺序：

1. 确认是否真的进入 CinderX JIT
2. 再做热点归因，确认时间真正花在哪些函数或路径上
3. 抓 HIR
4. 抓 LIR
5. 看最终机器码或 trampoline
6. 必要时结合 gdb、core dump、deopt 信息

重点关注：

• 不要在确认进入 CinderX JIT 之前就开始做热点归因
• 不要在没有热点归因的情况下直接盲看 HIR
• HIR 是否退化
• pass 前后形态是否变化
• deopt idx、frame layout、调用约定是否异常
• 最终输出必须贴出具体 HIR 片段，指出问题点，再给出修改方案

非 JIT 路线

分析顺序：

1. 字节码
2. uop
3. 机器码

重点关注：

• opcode / uop 形态差异
• 是否退回慢路径
• 是否存在启动期或 import-time 噪声

对比原则

• 先对齐命令口径
• 再对齐解释器和依赖
• 再比较性能
• 最后比较 HIR/LIR/机器码

优化点输出格式

一个合格的优化点输出至少包括：

1. 热点归因
2. 具体片段
3. 问题说明
4. 修改方案

不满足以上四项，不应把它算作一个完整的优化点。

性能口径定义

详细参考：references/performance-modes.md

四种口径：

1. CPython 解释执行 — stock CPython，不启 JIT
2. CPython JIT — stock CPython + JIT
3. CinderX 解释执行 — 带 cinderx 但不显式启 JIT
4. CinderX JIT — 显式启 JIT + HIR 证明

默认比较规则：

• JIT 和 JIT 比
• 解释执行和解释执行比
• 不同口径不能直接横向比较

口径边界：

• 安装了 cinderx 不等于已经进入 CinderX JIT
• 开了 PYTHONJITLOGFILE 不等于 benchmark 本体真的进了 JIT
• CPython JIT 和 CinderX JIT 不能共用同一套结论

baseline 的两种含义：

1. 口径基线 — 对照解释器/运行模式
2. 提交基线 — 改动前的 commit/branch

报告中必须显式写清当前 baseline 是哪一种。