dotnet-cpu-hot-paths

Files (1)

• SKILL.md

SKILL.md (first lines)

# .NET CPU 热路径

## 先看 JIT 生成的代码

- 数学上等价的 C# 写法，生成的机器码未必相同，值得多试几种
- 辅助方法内联后，寄存器分配、常量加载和指令顺序还会受周围代码影响，所以要看实际调用点，不能只看辅助方法本身
- 源码顺序会影响 JIT 输出，可以试着把互不依赖的计算交错排列，但别指望靠 C# 精确控制指令顺序
- 指令数、栈帧大小和机器码长度都不能直接代表性能；即使没有溢出到栈，瓶颈也可能在关键依赖链、加载延迟、寄存器间的数据搬运或缓存压力上
- x64 和 ARM64 尽量共用一套写法，确认某个架构的生成代码明显更差时再分开写

## 标量与 SIMD 的数据流

- 展开循环、把状态提到循环外、合并循环，都要算总账：能省下循环控制、方法调用和状态写回，但也可能带来代码膨胀和寄存器压力
- 临时值的生存期尽量短；中间结果是留着、重算还是重新读取，看哪种总成本更低
- 提前加载只有在能隐藏延迟时才划算；如果它让 JIT 用不上内存操作数，或让太多值同时存活，就等到快要用时再加载
- 在方法入口一次做完边界检查，之后逐步推进 `ref`，可以省掉重复的索引扩展、地址计算和范围检查；同样的逻辑用数组、`Span` 或 `ref` 来写，生成代码可能不同
- 只向量化部分计算时，向量结果要尽快用掉，少做元素提取，少在 SIMD 寄存器和通用寄存器之间搬运，也别写到栈上再读回来
- 拆开再拼回、清零后马上覆盖、提取标量再广播，这类中间步骤往往能换成更直接的等价写法
- 同一块内存既整体读成向量、又通过 `GetElement`、`ToScalar` 读取其中某个元素时，CSE 可能把两次向量读取合并成一个寄存器临时量，元素读取就无法再折叠成内存操作数；改为直接从内存读取该元素，通常能保住折叠
- 向量更宽、并行度更高不一定更快；转换、尾部处理和寄存器压力都要算进成本，有时窄向量甚至标量反而更快
- JIT 通常会消除 `IsSupported` 分支，但支持某个 ISA 不等于走那条路径更快，还要看工作量；按工作量选择路径的判断应放在核心循环外
- 通用向量 API 在所有目标 ISA 上都能生成高效代码时优先用它，否则再换成对应的 intrinsic

## 内联、泛型和内存布局

- 别滥用 `AggressiveInlining`，它也不保证一定内联：外层方法内联后，更深层的辅助方法仍可能受内联预算或深度限制；把核心循环或冷路径拆进单独的 `NoInlining` 方法，有时反而更快
- JIT 知道泛型实参的具体类型时，受约束调用和静态抽象成员调用通常会变成直接调用或被内联，值类型也不会装箱；调用实例成员则可能多一次空引用检查
- 通过 `in` 参数、`readonly` 字段等只读位置调用结构体的非只读成员时，编译器会先复制一份；成员内联后 JIT 可能把复制优化掉，但生成代码仍可能不如通过 `ref` 调用，不内联则会真的复制整个结构体
- 要避免这类防御性复制，可以把被调成员标成 `readonly`，或改从 `ref` 参数等可写位置调用
- `InlineArray` 适合存放固定大小的状态；要通过 `ref`、`Span` 或索引原地读写，体积较大时也不要按值传递
- `Unsafe.SkipInit` 去不掉方法级的 `.locals init`；只有局部变量清零确实造成明显开销时，才在适当范围内用 `SkipLocalsInit`

## 验证改写

- 任何改写都必须行为等价
- 只换局部写法、不动代码结构的改写，除非用户另有要求，每个受影响配置下的生成代码都要不变或更好
- 展开或合并循环、改变向量宽度这类结构调整往往有得有失，以基准测试结果为准
- 动态 PGO 可能改变内联、去虚拟化和代码布局，所以 FullOpts 和 Tier1+PGO 都要看；看 Tier1+PGO 时，先用真实的生产调用预热，再取最终的 Tier1 代码，内联预算和晋升阈值保持默认
- 改动涉及的每条 ISA 分派路径都要覆盖，例如原生 AVX-512、禁用 AVX-512、禁用 AVX 和 ARM64，并确认每种配置都真的执行到了改过的代码
- 要对比调用方的内联结果、调用数、栈帧和栈访问：被改的方法变短了，外层的内联决策也可能随之改变，反而多出真正的函数调用
- Tier1+PGO 的代码布局和寄存器分配本身就会波动；先对基线重复采样，只有差异超出这个范围，才能算到改写头上
- 生成代码只是少了指令、其余不变时，通常可以直接判定更好；如果换用了别的指令，例如 `vinserti128` 换成 `vpermq`，或整数重排换成浮点重排，要确认在目标微架构上的延迟和吞吐不比原来差，必要时跑基准

From HMBSbige/skills, MIT.

More from HMBSbige/skills