背景介绍
在算子开发结束和整网运行出现算子性能不达标两种场景下,需要对算子进行调优。本节以AvgPool算子为例,介绍通过专家系统算子优化分析功能, 从向量指令执行效率和流水打断两个维度分析,给出优化建议,提升算子性能。
Davinci芯片架构复杂化,人工基于Profiling数据识别性能瓶颈,门槛高、耗时长。Roofline模型以运算强度为横轴、每秒浮点运算次数为纵轴画图,描述芯片最佳性能和实际运行负载特性,反馈优缺点,给出优化方向。
专家系统操作
以HwHiAiUser用户为例执行以下操作。
- 参见《CANN 软件安装指南》安装Ascend-cann-toolkit包。
- 准备模型mobilenetv3,通过Profiling采集生成的profiling文件,ATC转换生成的OM文件、cce文件作为Roofline功能的输入文件。文件路径为${data_path}数据目录根路径。
- 配置环境变量。
. /home/HwHiAiUser/Ascend/ascend-toolkit/set_env.sh
- 执行分析命令。
msadvisor -d /home/HwHiAiUser/data -c model
-d参数数据指定算子仿真文件的路径,指定到数据目录的根目录(包含所有专家系统输入数据的目录);Roofline功能属于对模型的分析,所以-c参数配置值为model。
- 完成分析后,系统会将分析结果以打屏的形式展示。输出MobileNetV3模型内的算子瓶颈如下。
图1 Roofline模型的算子信息列表
问题分析
- 命令行结果展示TopN算子信息,字段解释如下。结果按照AI Core运行时间降序排列,优先解决时间占比高的算子问题。
字段 |
说明 |
Op Name |
算子名称。 |
AICore Time(us) |
AI Core运行时间,单位为us。 |
Bottleneck pathway |
瓶颈通路,即工作点最靠近roofline的通路。 |
Bottleneck Rate |
瓶颈率,即工作点占Roofline上限的百分比。 |
Bottleneck Pipeline |
占比最高的流水。 |
Pipeline Rate |
流水最高占比。 |
Bound Type |
瓶颈分类。 |
- 根据Roofline结果,可以快速获取当前模型的性能瓶颈点以及性能瓶颈通路。其中,AI Core Time与Bottleneck Rate可以综合衡量模型优化收益,如MobilenetV3/Conv/Conv2D的瓶颈率为25.91%,算子时间为293.7us,若优化后能提升到80%,收益估计为200us。
- 以下举例说明几个算子的分析过程:
- 根据Roofline结果,MobilenetV3/Conv/Conv2D算子为L2->L1 latency memory bound,bound ratio=25.91%。分析该算子的流水并行度,发现该算子耗时最大的为MTE2流水,占算子总耗时的91.50%,可知该算子阻塞点在MTE2流水搬运。可以检查数据搬运粒度是否过小,或存在搬运依赖。
- MobilenetV3/expanded_conv/depthwise/depthwise 算子为L1->L0A latency memory bound,bound ratio=35.45%。首先分析该算子的流水并行度,发现该算子耗时最大的为MTE2流水,占算子总耗时的46.66%,低于80%, 可知流水并行存在问题。
- MobilenetV3/expanded_conv_3/squeeze_excite/AvgPool 算子,距离屋顶最近的数据通路为L2->UB,bound ratio=13.86%,算子属于latency bound,首先进行流水并行度 分析,发现占比最大的Vector Pipeline,占比85.11%,说明流水并行度较好。但是Vector Pipeline耗时占比最大,在Roofline里面确实latency bound说明Vector的计算过程存在问题。需要分析Vector问题。
问题解决
- 不同的算子需要根据算子的具体问题具体制定解决策略,专家系统的算子瓶颈分析推荐可以参考算子优化分析样例的部分,这里不再重复介绍。这一节主要介绍如何根据专家系统Roofline模型的优化建议,快速识别性能问题。
- 分析MobilenetV3/expanded_conv/depthwise/depthwise算子的性能问题。根据专家系统的分析结果可知,该算子硬件利用率低,且各通路的瓶颈占比都很低,该算子为流水并行存在问题。根据优化建议“Reduce strong data dependencies between pipelines”,首先分析该算子各流水之间是否存在同步依赖。查看算子仿真流水图如下。MTE2流水中间存在很长一段时间的空闲时间,并且MTE2流水阻塞了MTE1 流水。确实存在流水打断的问题。
图2 流水打断
- 原始cce代码中首先使用MTE2搬运很大一部分Featuremap去进行cube计算,在cube计算结束后进行第二部分 Featuremap的搬运。

因此可以调整第二次Featuremap搬运指令的位置,将第二次Featuremap的搬运放到第一次搬运后面,这样第一次搬运完成之后可以直接进行第二次搬运。减少不同指令之间的数据依赖。
- 另外,根据优化建议“Eliminating improper instruction synchronization between pipelines”,代码中可能存在不合理的同步指令。分析CCE代码,发现代码中两条流水之间有pipe_barrier(PIPE_ALL) 指令。可以删除该指令进行优化。
结论
通过专家系统工具的分析,可以快速找出模型的Top瓶颈问题。并根据不同的瓶颈类型,给出对应的优化建议。根据优化意见,可以有针对性的进行性能分析,提升了模型调优效率。