编译与图优化深入阅读

主故事线

如果把这条线写完整，往往是这样展开的：先看到“图已经很规整了”，但 benchmark 还是慢，于是先沿着 1E-09 -> 1E-19 看图里到底贵在什么地方、能不能通过 fusion 去掉中间结果；接着发现图级优化已经做了不少，但性能仍然没有明显提升，就继续沿着 1E-32 -> 1E-33 看 lowering 和成本模型有没有把执行约束讲清楚；再往下走到 1D-08 -> 1D-15 -> 1D-18 -> 1D-29，会发现真正决定速度的常常是执行模型、kernel 组织和调度方式；最后回到 2.2 -> 2.6 -> 2.7A -> 2.9，确认 backend 视角下的改动是否真的把项目指标抬上去了。

端到端案例

一个更完整的编译优化过程，通常是从“图看起来没问题，但 benchmark 就是上不去”开始的。先沿着 1E-09 -> 1E-19 看图里到底贵在什么地方，确认 fusion 和中间张量有没有把成本压下来；再沿着 1E-32 -> 1E-33 看 lowering 和成本模型，确认问题是不是被停留在语义正确但执行不划算的层次；当性能还是不涨时，再去 1D-08 -> 1D-15 -> 1D-18 -> 1D-29 看 kernel 组织、执行模型和调度是否才是真正的瓶颈；最后回到 2.2 -> 2.6 -> 2.7A -> 2.9，确认 backend 侧的改动是否真的把项目结果拉起来。

阅读建议

• 先读长故事，再回到 编译与图优化正文 看摘要和清单。
• 如果你先想看 backend 视角，也可以直接跳到正文。
• 如果你关心问题归因，可以先从 Profiling 专题 进入。