Msprof Op Simulator Pipeline Analysis

---
name: msprof-op-simulator-pipeline-analysis
description: 使用 msprof op simulator 采集并分析昇腾 SIMD、SIMT 及混合算子的流水空泡、同步等待、忙碌阶段耗时和核间尾部，结合 trace.json、仿真 dump、热点与源码，生成 Markdown 分析报告和优化建议；经用户授权后修改代码、复测并生成 Markdown 优化对比报告。适用于指令流水诊断与有证据的优化，不用于仅有上板指标的性能归因。
---

# 仿真流水与 SIMD/SIMT 优化分析

使用本技能时，咨询和执行任务都必须先从 [msopprof 代码仓](https://gitcode.com/Ascend/msopprof) 读取 msopprof 与 msopprof simulator 的使用资料。先通过仓库 README 定位相关指南并读取正文，再回答工具用法或生成执行命令。

工具安装、环境配置、编译要求、参数、A2/A3/A5 与输入模式差异、采集和解析方法，均以读取到的对应版本正文为准。记录资料来源与版本。查询失败时查找本地相关工具或本地资料参考用法；缺少可靠说明时，分析已有数据并明确未核验部分，不能凭旧模板或记忆猜测用法。

先采集待分析版本的仿真数据，用流水图定位耗时发生的位置，再用源码、指令和必要的补充证据形成诊断与优化建议。既分析空泡，也分析持续忙碌却执行代价高的阶段；目标是缩短关键依赖链上的耗时。默认先交付 Markdown 分析报告和优化建议，再询问是否修改代码实施优化；代码修改以用户明确授权为前提。

## 采集基线

完成资料查询后，确认当前工程、启动方式、产品线和具体 SoC、输入类型；在新的实验目录中编译待分析版本、准备输入并采集仿真数据。记录 shape、dtype、核/线程配置、分块、源码与工具版本，保留实际命令、日志、退出状态、产物来源和精度结果。用户指定已有数据作为分析输入时，核验其来源、采集完整性及对应源码。

按读取到的工具资料确定本次采集或解析方法，并识别流水、热点及原始指令数据。区分算子调用、核和子核，避免混用多次运行、汇总和单核结果。片段数据仅支持其覆盖范围内的结论，不能证明完整耗时或正确性。

从源码与启动接口识别 SIMD Tensor/寄存器 VF、独立 SIMT Kernel 或 SIMD 调用 SIMT VF，记录实际 `gridDim`、线程数和编译期最大线程数。`PUSHQ`、`VECTOR` 或 RVEC 泳道名称不能单独证明编程模型；AIC/AIV MIX 是核间协作维度，不等同于 SIMD/SIMT 混合编程。

## 分析顺序

共同的统计口径、证据边界和同步归因见 [流水分析参考](references/pipeline-analysis.md)。按当前代码选择优化参考，不同时加载无关模式的条目：

- SIMD Tensor、寄存器 VF 或矩阵计算：[SIMD 技巧与流水映射](references/simd-optimization-map.md)。
- SIMT Kernel、SIMT VF 或 SIMD/SIMT 混合编程：[SIMT 技巧与流水映射](references/simt-optimization-map.md)。混合工程按片段分别分析，跨阶段依赖仍用共同口径。

1. **确认数据语义**：结合编程模型区分仿真指令流水和上板流水。查看实际 `pid/tid/ph/name/args`，确认时间单位、指令泳道、同步事件、VF 边界及源码字段。
2. **选定范围**：按算子、调用实例、核/子核分别分析；优先选择包含多个完整数据块的窗口。明确启动、稳态、尾块、排空；无法确定块边界时只报告局部窗口。
3. **区分耗时形态**：先判断是阶段间空泡、阶段自身耗时高，还是启动/排空或核间尾部。空泡按区间并集统计，同步等待单列；忙碌阶段看指令次数、数据量、地址模式和源码热点，不因无空泡就停止分析。
4. **查看关键依赖链**：在同一窗口比较搬入、计算、写回的交集，追踪拖延下一阶段或最后完成者的生产者。新架构 VF 与内部 RVEC 不重复累加；SIMT 直接读写 GM 时可能没有 MTE 搬运，不能据此认定没有访存或缺少双缓冲。
5. **追溯依赖**：结合 SET/WAIT 的方向、事件 ID、重复出现顺序、Buffer 地址和源码确认生产者。C API 的 mutex 在某些 trace 中没有独立区间，可从原始指令 dump 的 GET_BUF/RLS_BUF、bufId 与计数补齐顺序证据；此时不填造等待时长。等待事件与空泡同时出现只是线索，还需说明依赖如何阻挡下一次执行。
6. **匹配技巧与补证**：按对应映射表选择最能解释当前关键耗时的候选，将“已观察事实”和“待验证原因”分开。Cache、带宽饱和、Bank 冲突、spill、分支发散或 occupancy 不能只凭流水外观定因；先补对应地址、资源报告或已有计数证据。
7. **给出最小实验**：保存本轮基线分析报告，记录观察到的现象、依赖证据、根因假设和建议。每轮只改变一个可解释的设计点；需要联动 Buffer 与同步时说明改动组合。预先写出预期减少的 gap、指令、搬运或调度次数及可能增加的资源代价，供后续采集验证。Double Buffer、异步接口、Cache 策略等先核对目标架构与当前 API 前提，不把优化目录当成必做清单。

用户提供两份结果时，先分别分析各自的流水现象与依赖，再核对逻辑工作量、精度和采集范围，在对比报告中比较目标机制与完整仿真时序。减少冗余指令或搬运是合理优化，不要求物理指令数和流量始终不变，但要解释差异。热点 CSV 聚合时长不能直接相加作为算子耗时；仿真 wall time 或 trace span 不作为上板加速比。优化后重新判断瓶颈是否转移，不因覆盖率上升或局部 gap 缩短就宣称整体收益。

需要其他性能数据补证时，先依据所读工具资料确认数据含义与适用范围，使用已有数据或列出待采项，不自动将任务改成上板采集。不同重放或采样数据不能拼成同一条精确时间轴。

## 输出要求

每次分析都必须生成并保存一份 Markdown 分析报告，结果分析报告及最终回复统一使用下方固定四段模板。将采集记录归入“算子基本信息”，流水现象归入“关键数据”，依赖证据与根因判断归入“核心瓶颈”，实验建议归入“优化建议”；明细可在对应章节下展开或链接到日志、统计和证据文件，不另设一套并列的顶层报告结构。

将分析报告保存到用户指定目录或本次实验目录，例如 `analysis-report.md`，在回复中提供报告路径或链接和关键结论，不能只在聊天中给出分析。后续对比报告也采用固定四段模板，按基线登记的假设和预期变化给出相同口径的前后数据；实测未出现预期变化时保留结果并检查采集和假设。

没有仿真环境时分析已有数据或提供可执行命令，明确未运行部分；没有 trace 或 dump 时不生成空泡数字。

## 固定报告模板（默认用于结果分析）

### 模板启用规则

- 结果分析、诊断和调优结论使用固定模板；仅有命令指导、模式选择或采集前排障时，不强制套用结果报告。
- 默认 `TOPx = TOP5`；用户明确指定其他 `x` 时，统一调整三处 TOP 标题和条目上限。
- 数据不足 5 项时按真实数量输出，不补齐；没有可确认的条目时直接说明证据不足，不虚构排名。
- 每个 Top 条目都应尽量带 `数据来源`，指向本次文件及相关区间、PC 或源码位置。
- 当前模式或数据集不支持某项时，写 `N/A`、`未采集` 或 `不适用当前模式`；缺少基本信息时写 `未提供` / `未采集`，不要脑补。

### 固定标题

结果分析场景下，保存的 Markdown 报告和最终回复默认使用以下四段标题，不要自行改名：

```markdown
## 1. 算子基本信息
## 2. 关键数据 TOP5
## 3. 核心瓶颈 TOP5
## 4. 优化建议 TOP5
```

### 1. 算子基本信息

使用短表格或键值表，不使用 Top 5。默认字段：

| 字段 | 内容 |
|---|---|
| 模式 | simulator |
| 输入形态 | application / config / export |
| 算子名 / 目标对象 | 当前分析对象 |
| 芯片 / 仿真器 | A2/A3/A5、具体 SoC 和 simulator 类型 |
| 采集指标 | 当前启用的 `aic-metrics` 或主要分析视图 |
| 主要产物 | 当前引用的 CSV / bin / trace / dump |
| 数据来源 | 文件或产物类型 |

本节同时记录环境与资料来源/版本、源码和工具版本、编程模型、shape/dtype、核/线程配置、分块、实际命令、日志、退出状态、产物路径、采集完整性和精度验证状态；长记录可链接到本次实验文件。

### 2. 关键数据 TOP5

使用短表格，固定列：

| 排名 | 指标/对象 | 数值/现象 | 意义 | 数据来源 |
|---|---|---|---|---|

- 只放最值得看的关键数据，不变成全量指标列表。
- simulator 场景优先来自 `trace.json`、`core*_code_exe.csv`、`core*_instr_exe.csv`；同步顺序可补充原始 dump，`PMSampling` 仅在当前产品支持且实际采集时使用。
- 关键耗时注明核/子核、流水或 VF、区间、单位、指令/PC、同期其他流水及源码位置，区分空泡、忙碌阶段和头尾/负载问题；明细放在本节表后或链接到证据文件。
- 对照数据注明各自窗口和分母，不重复累加 VF 父范围与内部 RVEC，不将热点 CSV 聚合时长相加作为算子耗时。

### 3. 核心瓶颈 TOP5

使用短表格，固定列：

| 排名 | 瓶颈结论 | 判断依据 | 影响 | 数据来源 |
|---|---|---|---|---|

- 必须把“结论”和“依据”分开，说明观察证据、生产者/消费者依赖及可信度。
- 没有足够证据时写 `待确认`，明确缺少的证据，不把猜测写成确定事实。
- 不直接复述经验案例；只有当前现象匹配时，才能把经验作为辅助说明。
- 已被对照验证消除的瓶颈标为“基线瓶颈，当前已消除”，不要继续列作当前版本的瓶颈。

### 4. 优化建议 TOP5

使用短表格，固定列：

| 排名 | 建议 | 对应瓶颈 | 预期收益/目的 | 前提/来源 |
|---|---|---|---|---|

- 建议必须与“核心瓶颈 TOP5”逐项关联，通过瓶颈排名明确对应关系；只给当前模式和 API 支持的建议。
- 纯命令指导、环境准备或尚未验证的根因假设，不应冒充优化建议；需要补证的探索项在本节表后单列为“待验证实验”。
- 对有依据的建议，补充“现象 → 补证/依据 → 官方技巧 → 预期流水或指令变化 → 适用约束 → 最小对照实验”；实验尚未实施时明确标注，不将预期当成实测收益。
- 无证据支持的收益不填数字；对照报告记录收益、退化、瓶颈转移及未验证项，不能只报告覆盖率改善。

## 报告模板的模式差异处理

固定模板只有一套，字段解释按 mode 变化；本技能仅执行 simulator 指令流水分析：

- simulator 的 `trace.json` 是指令流水图依据；device 的 `trace.json` 是通算 / 通信相关流水图依据，不能混用。
- `PMSampling` 只出现在支持且实际采集的 simulator 场景。
- `TimelineDetail` 只属于支持的 device 场景，在本技能的 simulator 报告中写 `不适用当前模式`。
- 标题和表格列固定，数据来源按实际模式与产物填写；不适用项明确写 `N/A` 或 `不适用当前模式`。

## 确认并实施代码优化

交付分析报告后，若用户尚未授权代码修改，必须询问是否需要按报告建议修改算子、重新验证并生成 Markdown 优化对比报告；同时说明拟实施的设计点和受影响源码，使用户能基于报告作出选择。用户未明确同意前不修改算子，用户拒绝则结束于分析交付。用户已明确要求或在此前授权了相关代码优化时，沿用授权，不重复询问。

用户同意后：

1. 保留可复核的基线源码版本、输入、配置和采集产物，按已确认的建议实施最小改动；每轮实验遵循前述单一设计点和精度契约要求。
2. 重新编译、执行完整仿真和精度验证，在可比的输入、环境和采集范围下按相同统计口径比较；优化引起的分块、核/线程配置、指令和流量变化要说明原因。
3. 另存一份 Markdown 优化对比报告，例如 `optimization-comparison.md`，保留原分析报告。包含实际修改的文件与机制、前后环境和配置、关键流水/空泡/指令指标对照、精度结果、实际命令与日志及产物路径，并说明收益、退化或瓶颈转移及未验证项。

在回复中提供优化对比报告路径或链接和结果摘要。即使优化未改善、精度失败或无法完成复测，也要记录实际结果与具体原因；缺失指标标为未验证，不用预期数值代替实测，不将局部仿真变化表述为上板加速。

## 配套实测工程

[SIMD VF 流水诊断案例](https://gitcode.com/Ascend/msopprof/tree/master/example/sample_simd_vf_double_buffer)由 msopprof 仓库的 `example/sample_simd_vf_double_buffer` 维护，不随本 Skill 分发。使用时从该仓库获取与实际工具配套的版本，或使用用户提供的本地 msopprof 案例路径，按案例 README 构建与校验。工程来自 asc-devkit，使用 `__simd_vf__`，只提供数值正确、存在性能瑕疵的待诊断实现，以及输入生成和精度校验。先独立采集当前版本，从流水、指令和源码形成诊断，保存分析报告和最小实验预期；不要假设已有优化场景或读取历史报告作为结论。获得代码修改授权后，在实验副本实施一项建议、重新采集并另存对比报告，保留原始待诊断版本。该工程验证 SIMD 流水编排，不代表 SIMT 实测；建议取决于当前证据，不能仅凭 Buffer 名称判断是否需要双缓冲。