029、算子性能分析：profiling与性能模型

欢畅科技

338人浏览 · 2026-04-20 09:20:42

欢畅科技 · 2026-04-20 09:20:42 发布

029、算子性能分析：profiling与性能模型

从一次深夜调试说起

上周三凌晨两点，团队群里突然弹出一条消息：“新模型推理速度比预期慢了40%”。我盯着profiling数据看了十分钟，发现瓶颈在一个看似简单的卷积算子。硬件利用率显示只有35%，但算子本身的FLOPs计算应该能跑满70%以上。这种性能缺口往往不是单一问题，而是计算访存比、缓存行为、指令流水线多个因素交织的结果。

Profiling：看见真实发生了什么

Profiling不是简单的计时，而是理解硬件如何执行你的代码。我习惯从三个层面入手：

// 错误的做法：只测整体时间
auto start = std::chrono::high_resolution_clock::now();
run_kernel();
auto end = std::chrono::high_resolution_clock::now();
// 这样只能知道“慢了”，不知道“哪里慢”

// 应该分层profiling
void profile_kernel() {
    // 第一层：硬件计数器
    // 用perf或VTune抓cache miss、branch miss这些
    // 这里踩过坑：只关注CPI（每指令周期）会漏掉内存瓶颈
    
    // 第二层：软件时间线
    // 记录每个计算阶段、内存搬运阶段的耗时
    // 别用std::cout，开销太大，用内存缓冲区记录
    
    // 第三层：MLIR层面的IR执行统计
    // 很多编译期优化决策会影响运行时行为
}

实际项目中，我们给MLIR pass加了profiling插桩。某个matmul优化pass在测试集上表现很好，但上线后性能反而下降。后来发现是profiling开销改变了缓存访问模式，导致数据对齐从64字节变成了128字节——这种Heisenbug在性能调优中特别常见。

性能模型：预测与验证

性能模型不是数学公式的堆砌，而是对硬件行为的抽象理解。我常用的经验模型包含这几个要素：

计算瓶颈模型：理论峰值FLOPs × 实际利用率。但要注意，现代芯片的“峰值”是有条件的：AVX512单元和标量单元峰值不同，混合精度和单精度峰值也不同。某次优化中，我们把fp32换成fp16，理论加速2倍，实际只拿到1.3倍，原因是张量核心的fp16峰值只在特定形状下才能达到。

内存墙模型：这个最棘手。不仅要看带宽，还要看延迟隐藏能力。我们有个GEMM内核，计算访存比很高，按理说不该受内存限制。但profiling显示L1 cache thrashing严重。原因是MLIR的tiling策略虽然数学上最优，但没考虑硬件预取器的步长模式——把128×128的块切成64×64后，预取器反而跟不上了。

流水线模型：指令级并行和内存级并行的平衡。某次尝试展开循环8次，理论上应该减少分支开销，但IPC反而下降了。后来发现是寄存器压力太大，导致spill到栈上，内存访问成了瓶颈。

MLIR中的性能工具链

MLIR的profiling和传统HPC不太一样，得适应多层IR的特点：

// 在Linalg dialect层面加profiling
func.func @matmul_profiled(%A: tensor<1024x1024xf32>) {
  // 方法1：用MLIR的profiling intrinsic
  %t0 = call @llvm.readcyclecounter() : () -> i64
  linalg.matmul ins(%A, %B) outs(%C)
  %t1 = call @llvm.readcyclecounter() : () -> i64
  // 问题：这会把多个优化pass隔开
  
  // 方法2：用transform dialect做instrumentation
  transform.sequence {
    ^bb0(%arg0: !transform.any_op):
    // 在特定优化阶段前后插入探针
    %matmul = transform.structured.match ops{["linalg.matmul"]}
    transform.performance.probe %matmul : !transform.any_op
    // 这个能保留到lowering之后
  }
}

我们团队在MLIR中实现了自动性能建模pass，它会根据目标架构（比如A76还是X1）预测每个算子的性能，然后反馈给tiling和fusion决策。有次发现自动优化器总喜欢把小的elementwise op融合到大的卷积里，但实测性能下降。模型没考虑到的是：独立的小kernel能更好地利用DMA异步传输，融合后反而让计算单元等数据。