算力手记C++ & COMPUTING SYSTEMS
← AMD 专题与八个进阶单元

AMD / LAB 07 OF 08

rocprofv3：提出一个可由 trace 回答的问题

测量调用范围，分清 API 提交、kernel 和拷贝。

本单元 4 小时。本公司八个单元共 32h，三家公司共额外 96h 核心实践；这笔时间在共同路线之外，未压入厂商入门的44h。

本页是实践讲义。打开、阅读或复制命令不代表完成。新单元的 SDK、simulator 与硬件命令均未在教材建设中执行；自己的结果应按实际后端保存。

先备与马上可用的例子

30 · 可信测量、原始样本与性能模型38 · Streams 与 events：用依赖组织异步工作39 · ROCm 各层：一次请求由谁负责40 · HIP Reduction：从正确性到 profiling 问题

先完成：amd-06 →

直接打开机制图，边看边手推

PREDICT FIRST

具体问题与独立预期

输入与约定

对正确 reduction 运行 warmup=5、记录=20 次；小测试仍为 X→8。教学 trace 三段 [0,2],[2,5],[5,6]。

先根据输入写下自己的结果与理由，再展开参考推演；随后运行或检查实现。

对照参考结果与原因

教学区间总跨度为6，kernel段长3；这些数字不是实测。真实记录必须保留20行样本与范围定义，没有设备时留空。

性能结论是关于某个输入、实现、机器和测量区间的陈述。API 用时、device event 用时和端到端用时不能相互替代。

机制怎样连接起来

先写问题：“每次是否重复上传相同输入？”、“kernel 之间是否出现空洞？”选一个即可。rocprofv3 的 HIP API trace、kernel trace 和 memory-copy trace 是不同记录，开 API trace 不等于自动获得所有设备活动。

正式计时前先验证答案。区分包括分配/H2D/D2H 的端到端范围和只包围 kernel 的 event 范围；用单独运行采 trace，避免把开启大量跟踪时的时延当生产性能。这里不安排扫描所有硬件 counter，四小时内只研究一条已定义的假设。

保存原始样本与最小版本信息，而不是只截一张漂亮图。可在本地保留诊断日志，公开复现包只摘录与性能有关的参数；rocprofv3 的完整配置导出可能包含环境变量，不将它原样用作公开环境清单。

CHOOSE ONE EXECUTION PATH

按手头环境推进

CPU 路径可以先完成。额外的 SDK 或设备验证要有自己的运行记录；本单元的四小时不同时要求完成四个分支。安装等待超过本页预算时，留下阻塞条件，继续可做的数学、代码与协议工作。

CPU · 现有机器 · 本单元尚未验收

条件：现有 macOS 或 Linux；C++20 编译器或 Python 3 标准库。无需加速卡。

本分支做什么：写 CSV 验证器并分析明确标注的教学区间，不虚构硬件样本。

保存什么证据：保存自己的源码、输入、实际 stdout/stderr 和退出码；只证明 CPU 逻辑。

教材初始执行状态：not-executed。这不是对你个人学习进度的判断。

SDK · 编译与环境 · 本单元尚未验收

条件：已有兼容 ROCm/HIP 的 Linux 工具链。

本分支做什么：核对 rocprofv3 版本和选项；工具缺失只记录缺失。

保存什么证据：保存实际工具版本与编译命令；仅编译成功不能记成运行通过。

教材初始执行状态：not-executed。这不是对你个人学习进度的判断。

官方 simulator · 本单元尚未验收

条件：只有明确提供并且版本匹配的官方 simulator 才属于此分支。

本分支做什么：本线没有用仿真时间预测 AMD 实机速度。

保存什么证据：记录 simulator 名称、版本、输入、日志、退出状态；网页或 CPU 模型不算 simulator。

教材初始执行状态：not-executed。这不是对你个人学习进度的判断。

真实设备 · 本单元尚未验收

条件：用户已有并可使用的兼容设备或实验室环境；本单元不要求购买、租用或提交集群作业。

本分支做什么：以单独 tracing 和 timing 运行采集真实数据；保留 scope/单位/样本数。

保存什么证据：真实设备输出、同步点、设备型号和复现日志单独保存；未执行保持未通过。

教材初始执行状态：not-executed。这不是对你个人学习进度的判断。

READ → BUILD → BREAK → EXPLAIN

四小时，留下一个完整产出

可拆成多个时段。每次停下时保存代码、输入、实际结果和下一步，不用重新读整篇。没有通过当前检查时继续修正，不靠翻页推进。

1. 定义计时范围 · 30 分钟

  1. 画两条括号：端到端和 kernel-only；指出各自开始和结束的完成条件。
  2. 写一个要由 trace 回答的问题，预计能看到哪些 API/活动。

这一段的产出：一条性能假设

2. 准备测量驱动 · 40 分钟

  1. 在正确实现中增加5次预热和20次记录；每轮检查或校验最终结果，防止工作被省掉。
  2. 用 N=5 做正确性，再选一个受限较大 N 做测量，并保存确切输入。

这一段的产出：可重复驱动

3. 采样或离线分析 · 90 分钟

  1. 有设备才运行下方trace命令，先创建新的本次运行目录并从中执行自己二进制的绝对路径；不覆盖旧CSV。核对已安装--help支持三个flag，缺flag按该版本手册调整并记录。
  2. CPU 路径对教学区间计算持续时间、跨度和间隙，再写 CSV 解析器，拒绝 end<start 或缺少单位的行。
  3. 真实采样保留 raw_samples.csv，记录时钟和范围；没有设备不生成伪造20行硬件样本。

这一段的产出：真实 raw 数据或明确标注的教学 CSV 分析

4. 寻找证据 · 50 分钟

  1. 用 API/活动关联确认是否重复 H2D；找不到关联就保留未知，而不是猜测活动名称。
  2. 报告中位数和最小/最大值，说明样本数；不要只选最好一轮。
  3. 关闭 profiler 再进行独立计时，比较开启工具是否改变结果/开销。

这一段的产出：假设结论与反证条件

5. 英文汇报 · 30 分钟

  1. 用两分钟描述范围、数据、一个发现和一个限制。
  2. 把未采集的硬件 counter 写为未采集，不填零。

这一段的产出：性能短报告

EXPLICIT ENVIRONMENT / EXPLICIT STATUS

命令与可保存的起点

以下代码按各自环境使用，运行前完成对应步骤并核对版本。编译失败后停止，不运行目录中的旧二进制；每次采集日志使用新的运行目录。设备程序仅运行在你已有且可使用的环境中。

1. 仅已配置rocprofv3的设备环境；在新的本次运行目录执行，将二进制路径改为自己的绝对路径

环境：真实设备 · 状态：not-executed。核对官方 API / 工具说明 ↗

bash · 按说明保存到自己的练习目录
rocprofv3 --help
rocprofv3 --hip-trace --kernel-trace --memory-copy-trace --output-format csv -- /absolute/path/to/hip_sum

一个必须能解释的错误

错误情境：只开 --hip-trace，然后把 hipLaunchKernel 的 API 用时称为 kernel 执行时长。

为什么会错：API 返回与设备完成不是一个时间范围，且缺少 kernel activity 记录。

怎样修复：显式采 kernel/memory-copy trace，并根据完成事件定义设备和端到端范围。

EVIDENCE BEFORE ADVANCING

验收与面试追问

  • trace 问题足够具体，能写出什么结果会推翻假设。
  • 教学6/3和真实采样从命名到报告都分开。
  • 原始样本、范围、版本、正确性在同一复现说明中。

最后留下这几项

输入和预期、自己的源码或明确标为推演的状态表、实际命令/输出/退出码、一个失败与修复、后端与版本、尚未执行的部分。运行已有教学例子与独立完成修改分别记录。

1. API trace 能证明重叠吗？

对照中文要点与英文回答

只能看到 API 调用时序；确认设备活动重叠还要相应活动的实际开始结束及依赖。

API timing alone does not prove device overlap. I need the device activity intervals and their dependencies.

2. 为什么 profiler 与计时分开运行？

对照中文要点与英文回答

跟踪会增加开销并改变调度，适合诊断；性能基线需要写明工具是否开启。

Tracing can perturb execution. I use it to diagnose behavior and measure baseline timing separately.

3. 没有设备还能交什么？

对照中文要点与英文回答

一个拒绝坏数据的分析器、范围定义和采集命令计划；不能交硬件性能结论。

I can deliver an interval analyzer and a collection plan. Hardware performance remains unmeasured.

这些是依照本单元机制设计的追问，不是公司真题。个人验收仍依据实际代码、测试、测量与口述。

资料与版本核验

  • Using rocprofv3 ↗

    HIP tracing; kernel tracing; memory copy tracing; CSV output

    核验日期：2026-09-05。核验时 ROCprofiler SDK 文档为 1.3.5；执行前用已安装 rocprofv3 --help 核对本版选项并记录包版本。

  • HIP asynchronous execution ↗

    Streams, events and overlap requirements

    核验日期：2026-09-05。HIP latest / 7.15.0 页面；记录设备 asyncEngineCount 与实际 tracing 工具版本。

  • HIP reduction tutorial ↗

    Reduction stages and optimization

    核验日期：2026-09-05。HIP latest / 7.15.0 页面；本讲义的短输入和算法合同独立设计，不照抄优化 kernel。

正文、问题和实践设计依据公开资料独立撰写。官方页面的示例输出是资料中的结果，不是本机运行证据。latest 链接可能变化，请在自己的复现说明中保留实际版本。