文档
注册

Roofline模型的优化分析样例

背景介绍

Davinci芯片架构复杂化,人工基于Profiling数据识别性能瓶颈,门槛高、耗时长。Roofline模型以运算强度为横轴、每秒浮点运算次数为纵轴画图,描述芯片最佳性能和实际运行负载特性,反馈优缺点,给出优化方向。

专家系统操作

  1. 准备模型mobilenetv3,通过Profiling采集生成的profiling文件,ATC转换生成的OM文件、cce文件作为Roofline功能的输入文件。文件路径为${data_path}数据目录根路径。
  2. 单击选择并打开已编译完成的应用工程。
  3. 单击菜单栏Ascend > Advisor > Advisor,弹出专家系统工具界面 。如图1所示。
    图1 专家系统工具界面
  4. 单击图1界面左上角New Project按钮,打开专家系统配置界面。
    图2 OM only
  5. 图2所示设置对应参数并单击Start执行分析。
  6. 完成分析后,系统展示分析结果。输出mobilenetv3模型的Roofline分析结果如下。
    图3 分析结果Roofline展示

问题分析

  1. 命令行结果展示TopN算子信息,字段解释如下。结果按照AI Core运行时间降序排列,优先解决时间占比高的算子问题。

    字段

    说明

    Op Name

    算子名称。

    AICore Time(us)

    AI Core运行时间,单位为us。

    Bottleneck pathway

    瓶颈通路,即工作点最靠近roofline的通路。

    Bottleneck Rate

    瓶颈率,即工作点占roofline上限的百分比。

    Bottleneck Pipeline

    占比最高的流水。

    Pipeline Rate

    流水最高占比。

    Bound Type

    瓶颈分类。

  2. 根据Roofline结果,可以快速获取当前模型的性能瓶颈点以及性能瓶颈通路。其中,AI Core Time与Bottleneck Rate可以综合衡量模型优化收益,如MobilenetV3/Conv/Conv2D的瓶颈率为25.91%,算子时间为293.7us,若优化后能提升到80%,收益估计为200us。
  3. 以下举例说明几个算子的分析过程:
    1. 根据Roofline结果,MobilenetV3/Conv/Conv2D算子为L2->L1 latency memory bound,bound ratio=25.91%。分析该算子的流水并行度,发现该算子耗时最大的为MTE2流水,占算子总耗时的91.50%,可知该算子阻塞点在MTE2流水搬运。可以检查数据搬运粒度是否过小,或存在搬运依赖。
    2. MobilenetV3/expanded_conv/depthwise/depthwise 算子为L1->L0A latency memory bound,bound ratio=35.45%。首先分析该算子的流水并行度,发现该算子耗时最大的为MTE2流水,占算子总耗时的46.66%,低于80%, 可知流水并行存在问题。
    3. 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问题。

问题解决

  1. 不同的算子需要根据算子的具体问题具体制定解决策略。这一节主要介绍如何根据专家系统Roofline模型的优化建议,快速识别性能问题。
  2. 例子1:分析MobilenetV3/expanded_conv/depthwise/depthwise算子的性能问题。根据专家系统的分析结果可知,该算子硬件利用率低,且各通路的瓶颈占比都很低,该算子为流水并行存在问题。根据优化建议“Reduce strong data dependencies between pipelines”,首先分析该算子各流水之间是否存在同步依赖。查看算子仿真流水图如下。MTE2流水中间存在很长一段时间的空闲时间,并且MTE2流水阻塞了MTE1 流水。确实存在流水打断的问题。
    图4 流水打断
  3. 原始cce代码中首先使用MTE2搬运很大一部分Featuremap去进行cube计算,在cube计算结束后进行第二部分 Featuremap的搬运。

    因此可以调整第二次Featuremap搬运指令的位置,将第二次Featuremap的搬运放到第一次搬运后面,这样第一次搬运完成之后可以直接进行第二次搬运。减少不同指令之间的数据依赖。

  4. 另外,根据优化建议“Eliminating improper instruction synchronization between pipelines”,代码中可能存在不合理的同步指令。分析CCE代码,发现代码中两条流水之间有pipe_barrier(PIPE_ALL) 指令。可以删除该指令进行优化。

结论

通过专家系统工具的分析,可以快速找出模型的Top瓶颈问题。并根据不同的瓶颈类型,给出对应的优化建议。根据优化意见,可以有针对性的进行性能分析,提升了模型调优效率。

搜索结果
找到“0”个结果

当前产品无相关内容

未找到相关内容,请尝试其他搜索词