Moore Perf Compute 性能分析

1. 什么是性能分析？

性能分析 (Profiling)是识别 GPU 应用程序性能瓶颈的过程。通过分析关键指标，了解内核在 GPU 上的执行效率，找出限制性能的因素。

性能指标模块 (Sections)

Moore Perf Compute 按照分析目的，将性能指标划分为 3 个模块，在报告中以 Section 形式展示：

Section	用途
LaunchStats	内核启动配置和资源使用情况
MemoryWorkloadAnalysis	内存访问模式分析
SpeedOfLight	计算和内存吞吐量评估

Section 启用说明

所有 Section 默认启用，无需额外配置。指标会在重放过程中自动收集，生成报告后统一展示。

---

2. Roofline 模型

2.1 什么是 Roofline 模型？

Roofline 模型是可视化 GPU 性能上限的有效方式。它直观地显示内核性能与硬件极限之间的关系，帮助开发者快速定位性能瓶颈类型（计算受限或内存受限）。

信息

下文提到的"峰值 TFLOPS"和"峰值 GB/s"均指 S5000 架构的理论值。

2.2 物理瓶颈

所有 GPU 性能问题最终可归约为三类物理限制：

性能 = min(计算吞吐, 内存吞吐, 延迟隐藏效率)

瓶颈类型	物理根源	典型症状	优化方向
计算受限	FP32/FP16/INT8 计算单元饱和	高计算利用率，低内存利用率	减少 FLOPs、使用低精度
内存受限	全局内存带宽饱和	高内存利用率，低计算利用率	合并访问、共享内存缓存
延迟受限	指令流水线停顿	低计算利用率，低内存利用率	提高占用率、减少同步

关键洞察

在优化之前，必须先识别瓶颈类型。盲目优化可能导致无效工作。

2.2 Roofline 图表解读

    性能 (FLOPS)
      ↑
      │                    ╭─────────────── 峰值计算性能
      │                  ╱│
      │                ╱  │
      │              ╱    │
      │            ╱      │
      │          ╱        │
      │        ╱          │
      │      ╱ 内存带宽极限
      │    ╱              │
      │  ╱                │
      │╱                  │
      └───────────────────┴────────────→ 算术强度
     0                  脊点            (FLOPs/Byte)

区域	诊断	优化策略
脊点左侧	内存受限	增加算术强度（共享内存、数据重用）
脊点右侧	计算受限	减少 FLOPs 或使用更低精度
脊点位置	内存/计算平衡点	算法设计的理论目标

2.3 算术强度计算

算术强度 = 每秒浮点运算数FLOP / 每秒内存带宽总数。
指每从内存中读取一个字节的数据，程序可以执行多少浮点运算（FLOP），单位为 FLOPs/Byte。

对于 GEMM (C = A × B):
  FLOPs = 2 × M × N × K              # 每次乘累加算 2 次 FLOP

  内存访问取决于数据重用策略：

  策略 A: 无重用（每次从全局内存读取）
  内存访问 = (M×K + N×K + M×N) × sizeof(FP32)

  策略 B: 矩阵 B 完全缓存（典型共享内存实现）
  内存访问 = (M×K + N×K) × sizeof(FP32)

示例：M=N=K=1024, FP32, 策略 B
  FLOPs = 2 × 1024³ = 2.15 GFLOPs
  内存 = (1024² + 1024²) × 4 = 8 MB
  算术强度 = 2.15G / 8M = 269 FLOPs/Byte

  → 对于 S5000（峰值约 200+ FLOPs/Byte），处于计算受限区域边缘
  → 优化方向：增加数据重用（共享内存分块）可进一步提升性能

---

3. 如何使用性能分析工具？

3.1 重放机制 (Replay)

不是所有性能计数器都能在同一时间读取。为了获取完整指标集，需要多次执行内核：

3.2 可重现性 (Reproducibility)

为确保分析结果的可重现性，Moore Perf Compute 会强制串行化执行 kernel：

• 每次运行都会强制 kernel 串行执行
• 同一时间只能分析一个进程

为什么需要串行化？ 并发执行会导致 GPU 资源竞争，引入非确定性的性能波动。串行化可消除这种干扰，确保每次测量的一致性。

数据差异的可能原因：

原因	说明
系统负载变化	其他进程占用 GPU
GPU 温度变化	散热不良导致降频
后台服务	动态频率调整

提高可重现性的建议：

# 1. 关闭其他 GPU 程序（将 other_gpu_app 替换为实际进程名）
pkill -f other_gpu_app

# 2. 多次运行取平均值
for i in {1..5}; do
    mcu -o run_$i.mcu-rep ./my_app
done

# 3. 在稳定环境中测试

3.3 MUSA Green Contexts 支持

Green Contexts 是多上下文支持机制，允许多个进程/应用共享 GPU 资源：

┌─────────────────────────────────────────────────────────┐
│                   GPU                                   │
│  ┌─────────────┬─────────────┬─────────────┐            │
│  │   MPX 0     │   MPX 1     │   MPX 2     │  ...       │
│  │  (Context A)│  (Context B)│  (Context C)│            │
│  │   App 1     │   App 2     │   App 3     │            │
│  └─────────────┴─────────────┴─────────────┘            │
└─────────────────────────────────────────────────────────┘

识别 Green Context 结果：

• 报告标题栏的 Attributes 按钮会变成绿色
• Session 页面显示 Green Context Resources 部分
• 显示 MPX IDs 和 MP 数量

详细使用指南

如需了解 Green Contexts 分析的详细操作步骤和界面说明，请参考 用户指南 中的 Green Contexts 分析章节。

---

4. 性能分析三层模型

分析策略： 从 L1 发现问题 → 在 L2 定位内核 → 用 L3 理解根因