rocprof

rocprof是一个用于GPU性能分析的工具。通过配置input.txt文件,用户可以设定度量参数如Wavefronts、TCCHIT/MISS等,并指定特定的GPU和kernel。运行rocprof后,它会产生input.csv文件,包含kernel的执行信息如dispatchorder,GPUid等,以及各种性能指标如ALUstall、LDSbankconflict和缓存命中率。这些数据有助于理解和优化GPU程序的性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

rocprof 的使用

  • 申明一个input.txt文件, 大致如下[1]:
# 度量(Metrics)相关参数
pmc: Wavefronts VALUInsts SALUInsts SFetchInsts
# Counters相关参数
pmc : TCC_HIT[0], TCC_MISS[0]
# 支持的范围格式: "3:9", "3:", "3"
range: 1 : 4
# profiler 的 GPU
gpu: 0 1 2 3
# 具体的 kernel 函数名,删除该行可以实现对所有 kernel 进行 profile
kernel: simple Pass1 simpleConvolutionPass2

  • 运行
rocprof -i input.txt ./a.out
  • 产生input.csv文件数据
  • 查看参数
    • 默认参数
      Index - kernels dispatch order index
      KernelName - the dispatched kernel name
      gpu-id - GPU id the kernel was submitted to
      queue-id - the ROCm queue unique id the kernel was submitted to
      queue-index - The ROCm queue write index for the submitted AQL packet
      tid - system application thread id which submitted the kernel
      grd - the kernel’s grid size
      wgr - the kernel’s work group size
      lds - the kernel’s LDS memory size
      scr - the kernel’s scratch memory size
      vgpr - the kernel’s VGPR size
      sgpr - the kernel’s SGPR size
      fbar - the kernel’s barriers limitation
      sig - the kernel’s completion signal

    • rocprof --list-basic

    • rocprof --list-derived

      • ALUStalledByLDS: ALU因为LDS写入读取暂停的百分比
      • LDSBankConflict: LDS bank conflict 的百分比
      • L2CacheHit: L2缓存命中率
      • SALUBusy
      • VALUBusy
      • VALUUtilization
      • GPUBusy

可以参考的资源

[1] https://zhuanlan.zhihu.com/p/545296023

好的,我们来详细、清晰地解释R1、R2、R3这三个关键参数的科学计算方法,避免公式化,注重原理和实际操作。 **核心目标:** 这些参数都是为了更准确地估算在实际并行计算环境中,为了达到目标性能(每秒处理的任务数 `N_r`),到底需要多少个CPU核心 (`C`)。它们量化了理想线性扩展与实际运行之间的各种损耗。 --- ### **1. R1 - 单核性能衰减系数 (核心内损耗)** * **它代表什么?** 当你把一个原本在单核上运行的任务,放到多核并行环境中的一个核心上运行时,**这个核心实际用于有效计算的效率**。它小于100%,因为并行化本身会引入一些“内部”开销。 * **为什么会有衰减?** * **通信开销 (最主要):** 核心需要花时间和内存/缓存与其他核心交换数据(发送/接收消息、同步状态)。这段时间不能做计算。 * **同步开销:** 核心可能需要等待其他核心到达某个点才能继续(栅栏同步),这段时间是空闲的。 * **资源争用:** 多个核心竞争访问共享资源(如内存带宽、缓存、I/O通道)导致延迟。 * **并行库开销:** MPI、OpenMP等并行库本身的函数调用需要时间。 * **如何科学计算 R1?** * **核心原理:测量“无效”时间占比。** * **方法:** 1. **基准测试:** 在你的基准系统 (`C_t` 核) 上运行**单个**仿真进程实例(注意,是单进程,不是单核运行整个大任务)。使用**性能剖析工具** (Profiler) 进行监测。常用工具包括: * Linux: `perf`, `gprof`, `vtune` (Intel), `rocprof` (AMD) * 通用: OpenMP/MPI 内置的性能分析接口 (PAPI, Score-P), TAU, Scalasca 2. **测量关键时间:** * `T_total`: 该单个进程从开始到结束的总运行时间。 * `T_overhead`: 该进程中**不用于核心计算逻辑**的时间。重点测量: * **通信时间 (`T_comm`):** Profiler 会告诉你 MPI 函数(如 `MPI_Send`, `MPI_Recv`, `MPI_Wait`, `MPI_Barrier`)或进程同步点消耗的总时间。 * **I/O 等待时间 (`T_io`):** Profiler 会显示文件读写操作阻塞的时间。 * **锁竞争/同步等待时间 (`T_lock`):** 如果有共享内存同步(如锁、原子操作),测量等待锁释放的时间。 * *(其他开销如并行库管理时间通常包含在通信或同步中)* 3. **计算 R1:** ```plaintext R1 = (1 - (T_overhead / T_total)) * 100% ``` 其中 `T_overhead = T_comm + T_io + T_lock + ...` (测量到的所有非计算开销时间总和) * **例子:** * 一个纯计算任务,几乎没有通信和I/O,Profiler 测得 `T_overhead` 只有 `T_total` 的 2%,那么 `R1 = (1 - 0.02) * 100% = 98%`。 * 一个密集通信任务,`T_comm` 占 `T_total` 的 55%,`T_overhead` 主要是 `T_comm`,那么 `R1 = (1 - 0.55) * 100% = 45%`。 * **为什么比固定表格好?** 表格只是基于“任务类型”的粗略经验值(如通信密集型 45-60%)。**实际测量**更能精确反映你的**特定代码和问题规模**在**特定硬件**上的真实开销。不同算法、不同消息大小、不同网络都会导致 `T_overhead` 差异巨大。 --- ### **2. R2 - 多核协同效率因子 (核心间协同损耗 / 扩展效率)** * **它代表什么?** 当使用 `C` 个核心并行处理 `C` 个子任务时,相对于理想情况(速度提升正好是 `C` 倍),**实际能达到的效率百分比**。它衡量了核心数量增加带来的额外协调和通信成本。`R2` 通常随着核心数 `C` 的增加而下降。 * **为什么会有衰减?** * **通信开销放大:** 核心越多,需要交换的数据总量可能增加,或者通信路径更复杂(跨节点),导致总通信时间占比上升。 * **同步开销放大:** 让几百甚至几千个核心同步比让几个核心同步慢得多。 * **负载不平衡:** 分配给不同核心的子任务计算量不完全相等,导致快的核心等待慢的核心。 * **共享资源瓶颈:** 内存带宽、网络带宽、I/O带宽成为瓶颈,所有核心都受影响。 * **并行算法局限:** 有些问题有固有的不可并行部分 (Amdahl定律)。 * **如何科学计算 R2 (以区间形式)?** * **核心原理:测量实际加速比 (Speedup) 与理想加速比的比值。** * **方法:** 1. **选择参考点:** 在你的基准系统上,选择一个**较小规模**的并行运行作为参考。通常选择 `C_ref = 8` 或 `C_ref = 16` 核(这个规模下 `R2` 通常很高,接近 95-99%)。 2. **测量参考性能:** * `N_ref`: 在 `C_ref` 个核心上运行时,单位时间(秒)内完成的任务数(或进程数)。 * `T_ref`: 完成一批固定数量任务(比如 `K` 个)所需的总时间(秒)。 3. **测量目标规模性能:** 在**相同的硬件系统**上,使用 `C_target` 个核心 (`C_target > C_ref`,例如 32, 64, 128...),运行**完全相同的那批 `K` 个任务**。 * `N_target`: 在 `C_target` 个核心上运行时,单位时间(秒)内完成的任务数(或进程数)。 * `T_target`: 完成那批 `K` 个任务所需的总时间(秒)。 4. **计算实际加速比 (`S_actual`):** ```plaintext S_actual = T_ref / T_target (用时间算) 或者 S_actual = N_target / N_ref (用吞吐率算) ``` 两者本质相同,表示 `C_target` 核比 `C_ref` 核快了多少倍。 5. **计算理想加速比 (`S_ideal`):** ```plaintext S_ideal = C_target / C_ref ``` 这表示如果扩展是完美的线性,`C_target` 核应该比 `C_ref` 核快多少倍。 6. **计算 R2 (效率):** ```plaintext R2 = (S_actual / S_ideal) * 100% ``` * 这个 `R2` 是 `C_target` 核相对于 `C_ref` 核的扩展效率。 * 它量化了从 `C_ref` 核扩展到 `C_target` 核时的效率损失。 * **得到区间:** 为了得到一个针对 `C_target` 核数的效率**区间**,你需要: * **多次实验:** 对 `C_target` 进行多次运行(例如 5-10 次)。每次运行可能因为系统抖动、网络波动、负载不平衡程度不同而导致 `T_target` 或 `N_target` 略有不同。 * **计算每次的 R2:** 对每次运行,都按步骤 4-6 计算出一个 `R2`。 * **确定区间:** 取这多次运行得到的 `R2` 值的**最小值**和**最大值**,形成 `[R2_min%, R2_max%]` 区间。这个区间反映了在该核数下效率的波动范围。 * *(更严谨:可以计算平均值和标准差,但区间更直观)* * **例子:** * `C_ref = 8` 核,`T_ref = 100秒` 完成 `K` 个任务。 * `C_target = 64` 核。运行 5 次,`T_target` 分别为:`18秒`, `17秒`, `19秒`, `18.5秒`, `17.8秒`。 * `S_ideal = 64 / 8 = 8` (理想快8倍) * 计算每次 `S_actual = 100 / T_target`: * 100/18 ≈ 5.556 * 100/17 ≈ 5.882 * 100/19 ≈ 5.263 * 100/18.5 ≈ 5.405 * 100/17.8 ≈ 5.618 * 计算每次 `R2 = (S_actual / 8) * 100%`: * 5.556 / 8 * 100% = 69.45% * 5.882 / 8 * 100% = 73.53% * 5.263 / 8 * 100% = 65.79% * 5.405 / 8 * 100% = 67.56% * 5.618 / 8 * 100% = 70.23% * `R2` 区间 = `[65.79%, 73.53%]` ≈ `[66%, 74%]` (向上取整便于应用)。 * **为什么比固定表格好?** 表格给出的是非常笼统的经验值(如64核效率90%)。**实际测量**考虑了你的**特定应用**在**特定硬件配置**(尤其是网络!)和**特定问题规模**下的真实扩展性。通信模式、负载均衡程度对 `R2` 影响极大,表格无法涵盖。 --- ### **3. R3 - CPU架构等效系数** * **它代表什么?** 不同CPU架构(X86, ARM, PowerPC等)在执行**相同的仿真计算任务**时,**相对性能效率的差异**。它以基准架构(通常是X86)为100%,其他架构按其相对性能打折。 * **为什么会有差异?** * **指令集差异 (ISA):** 不同架构的指令集不同,执行相同操作的指令数和效率可能不同。SIMD指令能力差异巨大。 * **微架构差异:** 流水线深度、分支预测、缓存大小/结构、内存控制器设计等直接影响IPC(每时钟周期指令数)。 * **编译器优化能力:** 编译器对不同架构的代码生成和优化成熟度不同。 * **数学库优化:** BLAS, LAPACK等关键数学库针对特定架构的优化程度不同。 * **如何科学计算 R3?** * **核心原理:在可比条件下,测量目标架构相对于基准架构(X86)执行相同核心计算代码的速度比(或吞吐率比)。** * **方法 (标准化基准测试):** 1. **提取计算核心:** 从你的仿真应用中,提取出**最核心、计算最密集、最具代表性**的计算内核(Kernel)。这应该是最能体现你应用计算特性的部分。 2. **准备测试程序:** 编写一个独立的、可重复运行的程序,主要就是这个核心计算内核。它应该: * 接受输入参数(如问题规模)。 * 执行核心计算。 * 输出执行时间(或计算速率如 FLOPS、每秒处理数据量)。 3. **统一测试环境:** * **操作系统:** 尽量相同版本(如 Ubuntu 22.04 LTS)。 * **编译器 & 版本:** **必须完全相同**(如 GCC 12.3 或 Clang 15.0)。 * **编译器标志:** **必须完全相同**(如 `-O2 -march=native` 或 `-O3`)。如果你想模拟文档中“编译器一致且不开启优化”的条件,就用 `-O0`。 * **关键库版本:** 如数学库 (OpenBLAS, MKL, BLIS),MPI库 (OpenMPI, MPICH) **必须完全相同版本**。 4. **运行基准测试:** * 在**基准系统 (X86)** 上运行测试程序多次,记录平均执行时间 `T_x86` 或平均计算速率 `Perf_x86`。 * 在**目标系统 (如 ARM)** 上运行**完全相同的**测试程序(使用相同的二进制或相同源码在目标架构编译)多次,记录平均执行时间 `T_arm` 或平均计算速率 `Perf_arm`。 5. **计算 R3:** ```plaintext R3 = (Perf_arm / Perf_x86) * 100% // 使用速率计算更直观 ``` 或者 ```plaintext R3 = (T_x86 / T_arm) * 100% // 时间比,结果相同 ``` * 这个 `R3` 表示在**完全相同的软件栈和优化水平下**,目标架构运行你应用的**核心计算部分**相对于基准X86架构的效率百分比。 * **例子:** * 在相同编译器(`GCC 12.3 -O2`)、相同数学库(`OpenBLAS 0.3.23`)下: * X86服务器 (Intel Xeon Gold 6348): `Perf_x86 = 1000 GFLOPs` * ARM服务器 (Ampere Altra M128): `Perf_arm = 850 GFLOPs` * `R3 = (850 / 1000) * 100% = 85%` * **为什么比固定表格好?** 表格(如ARM 70-95%)范围太宽泛,且未考虑**你的具体计算负载**。**实际测试**直接测量**你的核心代码**在**可控环境**下的跨架构性能差异,结果更精确、更有针对性。不同应用的瓶颈(浮点、整数、内存访问)在不同架构上表现差异很大。 --- ### **总结与关键点** 1. **R1 (单核损耗):** 通过 **Profiling 单进程**,精确测量**非计算开销时间 (`T_overhead`)** 占总时间 (`T_total`) 的比例。`R1 = (1 - T_overhead/T_total) * 100%`。**实测优于任务类型估算。** 2. **R2 (多核协同损耗):** 通过 **扩展性测试**,测量目标核数 (`C_target`) 相对于一个较小参考核数 (`C_ref`) 的**实际加速比 (`S_actual`)** 与**理想加速比 (`S_ideal = C_target / C_ref`)** 的比值。`R2 = (S_actual / S_ideal) * 100%`。进行**多次测试**取 `R2` 的**最小值和最大值**得到区间 `[R2_min%, R2_max%]`。**实测扩展性远优于固定效率表。** 3. **R3 (架构差异):** 通过 **标准化的核心计算内核测试**,在**完全相同的软件栈**下,测量目标架构相对于基准X86架构的**性能比率**。`R3 = (Perf_target / Perf_x86) * 100%`。**针对你应用核心代码的实测远优于通用架构表格。** **核心思想:** 这三个参数的“合理计算”都依赖于**针对你的特定应用代码、你的特定硬件环境、你的目标问题规模**进行**实际测量和性能分析**。专利文档中的表格提供的是在缺乏这些测量数据时的**非常粗略的经验起点**。要获得准确的核心数 `C` 估算,进行这些测量是至关重要的步骤。这些测量本身也是性能优化和系统调优的标准实践。
07-16
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值