我要评分

文档获取效率

文档正确性

内容完整性

文档易理解

在线提单

论坛求助

昇腾小AI

性能调优建议

在执行完Profiling数据导出命令“python3 msprof.py export summary -dir xxx”后，会在屏幕打印相关性能调优建议，具体如下：

如果没有调优建议，相应项目结果显示NA。

基于单算子性能数据cube或vector利用率优化建议。
优化建议原则：

单算子数据分析时，发现算子满足cube或vector使用率小于预设阈值（80%），cube或vector利用率低，需要提升利用率。

图1 Low vector(cube) computing usage
基于单算子性能数据vec_bankgroup_cflt_ratio或vec_bank_cflt_ratio优化建议。
优化建议原则：

单算子数据分析时，发现算子满足vec_bankgroup_cflt_ratio或vec_bank_cflt_ratio使用率大于预设阈值（4%），提示用户bank冲突。

图2 The vector bank conflict has reached the upper limit
基于单算子性能数据memory bound优化建议。
优化建议原则：

单算子数据分析时，发现部分算子满足memory bound大于设定阈值（1），同时对应所有算子的耗时和大于总计算时间设定阈值（50%），需检查数据搬运的burthlength是否较小、是否存在重复搬运。

图3 Low data memory handling efficiency
基于单算子性能数据vector bound优化建议。
优化建议原则：

单算子数据分析时，发现算子满足vector bound大于设定阈值（1），需检查vector指令的repeat是否较小、是否频繁设置vector mask。

图4 Check repeat counts and vector mask
基于单算子性能数据cube算子的vector bound优化建议。
优化建议原则：

单算子数据分析时，发现cube算子的vector利用率高于设定阈值（80%），同时算子耗时超过阈值（20us），需要降低cube算子的vector利用率，提升cube利用率。

图5 Cube operators spend too much time on vector computing
基于单算子性能数据scalar bound优化建议。
优化建议原则：

单算子数据分析时，发现算子scalar利用率高于设定阈值（80%），需要降低其scalar利用率，提高cube或者vector的利用率。

图6 High scalar computing usage
基于单算子性能数据AI CPU切换AI Core优化建议。
优化建议原则：

task类型为AI CPU的算子StridedSliceGrad耗时大于设定阈值（20us）时，建议将task类型切换为AI Core。

AI CPU算子耗时大于设定阈值（20us）且输入类型为INT64时，建议将输入类型转换为INT32，并将task类型切换为AI Core。

图7 Try to cast the data type to INT32 for AI Core operators, and try StridedSliceGrad on AI Cores
基于整网性能数据相邻算子的间隔大于阈值的优化建议。
优化建议原则：

根据配置的时间间隔阈值，如果前后两个算子的间隔（上一个算子执行结束到下一个算子执行开始的时间间隔）大于该阈值（10us），同时调度等待时间占总耗时阈值（3%），即存在等待时间较长的算子。

图8 Task waiting time has reached the upper limit
基于整网性能数据transData算子数量优化建议。
优化建议原则：

存在transData算子，且数量超过设定的阈值（2），需检查是否有使用transData算子的必要性。

图9 Check and reduce the transData
基于整网性能数据AI CPU优化建议。
优化建议原则：

整网数据分析时，存在AI CPU算子，建议优化并去除网络中的AI CPU算子。

图10 Check and reduce AI CPU operators
基于整网性能数据memory_workspace优化建议。
优化建议原则：

检测到性能数据memory_workspace中存在不为0的数据，建议优化memory_workspace。

图11 Check and reduce the memory workspace
基于整网性能给出模型瓶颈分布的优化建议。
优化建议原则：

通过模型中全部AI Core算子的pmu信息计算模型的Cube、Vector、Scalar和MTE利用率，并根据模型的Cube利用率是否超过50%决定模型是否Cube亲和。

图12 Model Bottleneck Analysis
基于AI Core算子和AI CPU算子并行执行的优化建议。
通常AI Core算子与AI CPU算子之间是并行执行的，当有算子依赖的情况下，AI CPU算子会串行等待AI Core算子，如果这样的AI CPU算子过多，则会成为整体性能的瓶颈。

优化建议原则：

一个迭代内AI CPU算子单独执行的时间占计算时间的比例大于预设阈值（5%），提示用户通过查看Timeline找到与AI Core串行的AI CPU算子，利用算子替换、算子数据类型修改及算子融合等手段将其切换为AI Core再执行。

图13 Operator Parallelism
基于通信耗时分析得到优化建议。
由于集合通信算子是同步执行的，若集群中存在慢节点，则会由于木桶效应，拖累整个集群的性能。

优化建议原则：
1. 查看一个迭代内是否存在通信算子等待时长比例（Wait Time Ratio）大于阈值（0.2）的卡：
  1. 若存在，此迭代存在通信瓶颈，可通过14.b进一步查看。
  2. 若不存在，初步断定此迭代不存在通信瓶颈，可进一步查看总体带宽使用率情况。
2. 找到通信算子等待时长比例（Wait Time Ratio）最大的卡，查看其传输前同步时长比例（Synchronization Time Ratio Before Transit）是否大于阈值（0.2）：
  1. 如果大于，则存在慢卡（等待时长比例最小的卡），需查看慢卡的前向反向计算时间；若该慢卡的前向反向计算时间远大于其他卡，则需要检查负载是否均衡和芯片是否故障；若该卡的前向反向计算时间基本和其他卡相同，则需检查数据预处理时间；
  2. 否则，存在链路异常的情况，需查看是否有链路故障或者通信量过小的情况。
- 等待时长比例（Wait Time Ratio） = 等待时长（Wait Time）/ (等待时长（Wait Time） + 通信时长（Transit Time）)，等待时长比例越大代表卡的等待时长占总通信耗时越长，通信效率越低。
- 传输前同步时长比例（Synchronization Time Ratio Before Transit） = 传输开始前同步时长（Synchronization Time） / (传输开始前同步时长（Synchronization Time） + 通信时长（Transit Time）)，同步时长（Synchronization Time）指第一次传输数据前的同步时长，传输前同步时长比例越大说明通信效率越低，可能存在慢卡的情况。
图14 基于通信耗时分析
基于通信矩阵分析得到优化建议。
集群场景中的慢链路一般有以下两种情况：
- 个别的慢链路导致少数卡之间的通信时间增长，其他卡需等待其通信完成，从而拖累整个集群的性能。
- 存在带宽或通信算子异常的情况，导致全网链路无法达到正常的带宽速率，所有卡的通信时间增长，这种这种情况下没有典型的慢卡和慢链路。
通过通信矩阵对HCCS、PCIE和RDMA进行分析，针对每种链路类型的平均情况，给出瓶颈分析及调优建议；针对存在慢链路的情况，给出慢链路的全部信息及调优建议。
分析建议如下：
1. 三种链路类型的耗时占比信息。
2. 每种链路类型的具体情况：
  1. 链路平均信息：包含传输总耗时，平均带宽及平均大包传输率，根据信息给出调优建议。
  2. 最慢链路信息：链路带宽小于平均带宽20%时输出最慢链路相关信息，包含传输时长、传输大小、传输带宽、带宽利用率以及大包比例，根据信息给出调优建议。
优化建议原则：
1. 若带宽使用率大于0.8，说明带宽使用正常，全网链路无瓶颈，可参考15.b进一步查看；
2. 若通信包比例大于0.8，说明通信包尺寸无异常，则链路配置有问题或存在链路劣化问题，可参考15.c进一步查看；
3. 通信包尺寸过小，说明每次通信传输的包太小，导致带宽使用率不高，存在带宽的瓶颈。
图15 基于通信矩阵分析

父主题： summary数据说明