📚 课程目录第3章性能计数器基础

3. 性能计数器基础

3.1 核心原理：性能计数器到底是什么

性能计数器（Performance Counter）是处理器、GPU 或其他硬件单元内部一组可编程的硬件寄存器，用于记录特定微架构事件的发生次数或持续周期。以 NVIDIA GPU 为例，SM（Streaming Multiprocessor）内部布置了数十个硬件事件监测点，每个监测点对应一个事件信号，例如“已发射的 warp 指令数”“L1 缓存未命中次数”“全局内存事务数”等。当程序在 GPU 上执行时，这些事件信号会驱动计数器递增，最终形成可量化的性能画像。

与直觉不同，性能计数器并非“测量工具”从外部观测程序，而是硬件自身在运行过程中同步记录的副产品。它不打断执行流，也不引入额外的插桩代码，因此能以极低的开销获得接近真实的硬件行为数据。Nsight Compute 的核心工作，就是读取这些硬件计数器，并将其映射到 CUDA 内核的源代码与 SASS 指令上，帮助开发者定位性能瓶颈。

  关键认知：性能计数器记录的是“硬件事件”，而非“程序逻辑”。例如，一个 if 分支在源代码中只出现一次，但若 warp 内线程发散，硬件会执行两次分支路径，对应的指令计数事件就会增加。理解这一差异，是解读计数器数据的前提。

3.2 硬件计数器与软件计数器

根据计数器的实现位置与采集方式，可以将其分为两大类：

维度	硬件计数器	软件计数器
实现位置	处理器/GPU 芯片内部专用寄存器	驱动程序或运行时库中的内存变量
采集方式	硬件信号直接驱动递增，零软件开销	在代码路径中插入指令，执行时更新
精度	周期级精确，可关联微架构事件	受采样位置影响，通常为粗粒度
典型代表	sm__sass_thread_inst_executed, l1tex__t_sector_hit_rate	CUDA 事件（cudaEvent）、nvprof 的 API 耗时
局限性	数量有限，需分组复用；部分事件不可同时采集	无法观测芯片内部微架构行为

在 Nsight Compute 中，绝大多数分析指标（如吞吐率、缓存命中率、占用率）都源自硬件计数器。软件计数器主要用于测量内核启动开销、API 调用耗时等粗粒度时间信息。两者互补：先用软件计数器定位耗时异常的内核，再用硬件计数器深入分析该内核的微架构瓶颈。

3.3 计数器分类体系

NVIDIA GPU 的硬件计数器可按硬件单元和数据属性两个维度分类。按硬件单元划分，主要包括以下类别：

执行单元计数器：记录 SM 中指令发射、执行、停顿的事件。例如 sm__inst_executed_pipe_fma 表示 FMA（融合乘加）管道执行的指令数，sm__warp_issue_stalled_* 系列则记录 warp 停顿原因。
内存层次计数器：覆盖 L1 缓存、L2 缓存、全局内存、共享内存、纹理/表面路径。典型事件包括 l1tex__t_sector_hit_rate（L1 命中率）、lts__t_sector_op_read_hit_rate（L2 读命中率）、dram__bytes_read.sum（DRAM 读字节数）。
互连与数据传输计数器：记录 SM 与 L2 之间、GPU 与主机之间的数据传输量，如 sysmem__bytes_read.sum。
电源与时钟计数器：记录 SM 时钟频率、显存时钟频率、功耗估算值，用于判断是否因功耗墙导致频率下降。

按数据属性分类，则可分为事件计数（如“发生了多少次 L2 未命中”）、周期计数（如“SM 处于活动状态的周期数”）和派生比率（由两个或多个基础计数计算得到，如“SM 利用率”= 活动周期 / 总周期）。Nsight Compute 的 Speed of Light 页面展示的“Compute (SM) Throughput”和“Memory Throughput”就是典型的派生比率指标。

3.4 方法流程：从计数器到性能洞察

在实际分析中，直接面对数百个计数器名称容易迷失。推荐采用以下流程：

明确分析目标：是分析计算瓶颈、访存瓶颈，还是指令调度效率？目标决定了需要关注哪类计数器。
使用 Nsight Compute 的 Section 预定义组：例如 MemoryWorkloadAnalysis 会自动采集并计算缓存命中率、内存带宽利用率等关键指标，无需手动挑选计数器。
查看 Speed of Light 页面：快速判断内核是计算密集型还是访存密集型，确定下一步深入方向。
深入 Warp State 与 Schedule 分析：若计算吞吐率低，查看 sm__warp_issue_stalled_* 计数器，定位是等待数据、等待执行资源还是分支发散导致。
交叉验证：修改代码后重新采集，对比计数器变化是否与预期一致。

以下是一个典型的 Nsight Compute 命令行采集示例：

# 采集内核的访存与执行指标，输出到独立目录
ncu --set full --section MemoryWorkloadAnalysis \
    --section ComputeWorkloadAnalysis \
    --launch-count 1 \
    -o profile_result ./my_cuda_app

# 查看已采集的计数器列表
ncu --import profile_result.ncu-rep --page details

3.5 案例：矩阵乘法的计数器解读

以经典的 SGEMM（单精度矩阵乘法）为例，假设内核的 Speed of Light 显示 Compute Throughput 为 92%，Memory Throughput 仅为 35%。此时应重点关注执行单元计数器：

sm__inst_executed_pipe_fma.avg.pct_of_peak_sustained_active  89.4
sm__inst_executed_pipe_alu.avg.pct_of_peak_sustained_active  3.2
sm__warp_issue_stalled_fixed_latency_divergence              12.5%
sm__warp_issue_stalled_wait                                  8.3%

FMA 管道利用率接近 90%，说明计算单元已高度饱和；ALU 管道占用极低，表明没有多余的整数运算拖累。此时性能瓶颈在计算而非访存，优化方向应聚焦于减少指令总数（如使用向量化 FMA）或提高指令级并行度，而非增加缓存命中率。

若另一版本的内核 Compute Throughput 仅为 45%，而 sm__warp_issue_stalled_long_scoreboard 占比高达 40%，则说明 warp 大量停顿在等待全局内存数据返回。此时应检查 L1/L2 命中率，并考虑使用共享内存进行数据分块复用。

3.6 误区与复盘

常见误区一：将所有计数器一次性全部采集。GPU 硬件计数器数量有限，且部分计数器位于同一物理单元，无法同时采集。Nsight Compute 会自动进行多轮 pass 分组采集，但 pass 数过多会显著增加运行时间，甚至因时钟调制影响结果准确性。建议每次只采集与分析目标相关的 Section。

常见误区二：忽略计数器之间的关联性。单个计数器数值本身意义有限。例如 l1tex__t_sector_hit_rate 为 80% 看似不错，但如果 L2 命中率仅为 30%，则整体访存效率仍然低下。必须结合各级缓存命中率、DRAM 带宽利用率综合判断。

常见误区三：将计数器数值直接等同于程序行为。编译器优化、指令重排、warp 调度策略都会影响计数器结果。同一份源代码在不同编译选项下，计数器数值可能有显著差异。分析时应同时查看 SASS 汇编，确认实际执行的指令序列。

复盘要点：性能计数器是硬件行为的“显微镜”，但需要正确的分析框架才能发挥价值。建议每次分析前先记录内核的基线指标（运行时间、SM 吞吐率、访存吞吐率），再逐步深入。当修改代码后，优先对比这些基线指标的变化方向，再定位具体是哪个硬件单元的行为发生了改变。这种“先整体后局部”的策略，能有效避免在数百个计数器名称中迷失方向。