关于深度学习:MegEngine-使用小技巧用-mperf-进行安卓-opencl-算子的-roofline-分析

前言

• roofline 剖析是一种简略评估以后计算工作对以后平台计算 / 访存能力的利用状况的办法，能够帮忙剖析算子的优化方向和优化后劲。mperf 实现了安卓 mali/adreno 两种 gpu 平台的 roofline 剖析能力，上面以 mali 平台为例，简略介绍一下操作步骤。

编译和集成

• 下载 repo 代码

  git clone https://github.com/MegEngine/mperf.git
  git submodule update --init --recursive

• 编译装置

  ./android_build.sh -g mali
  cmake --build <mperf_build_dir> --target install

• 我的项目集成

  set(mperf_DIR /path/to/your/installed/mperfConfig.cmake)
  find_package(mperf REQUIRED)
  target_link_libraries(your_target mperf::mperf)

  对于编译和集成局部，详见 mperf readme

获取 roofline 数据

• 获取 opencl 算子执行过程的 GFLOPs 和 GBPs

  // define the measurement set
  mperf::GpuCounterSet gpu_set = {
      mperf::GpuCounter::GFLOPs,
      mperf::GpuCounter::GBPs,
  };
  mperf::XPMU xpmu(gpu_set);
  xpmu.run();
  
  ... // add your opencl kernel calls

  具体测试样例，参见 mali_gpu_pmu_test

• 获取以后 gpu 平台的峰值计算能力和访存带宽

  • 将编译阶段失去的 build_dir/apps 目录下的 gpu_inst_gflops_latency 和 gpu_spec_dram_bw 拷贝到手机上执行，即可拿到 gpu 的理论峰值算力和峰值带宽

  峰值性能测试的具体逻辑，参见 gpu_inst_gflops_latency 和 gpu_spec_dram_bw

绘制 roofline

• 上一步拿到了 opencl 算子执行过程的 GFLOPs 和 GBPs 和 gpu 的实测峰值算力和峰值带宽，当初能够借助 mperf plot_roofline 脚本绘制 roofline 曲线：

  • 编辑 roofline_data.txt:

    # params for plotting roofs, gpu peak calculation and memory ability
    memroofs 26.3
    mem_roof_names 'DRAM' 
    comproofs 1159         
    comp_roof_names 'FMA'   
    
    # omit the following if only plotting roofs
    # the measured data for your opencl kernel call, AI is measured_GFLOPs/measrured_GBPs
    AI 15.5                 
    FLOPS 261               
    labels 'FMA, DRAM' 

  • 执行 python 脚本:

    python3 plot_roofline.py ./roofline_data.txt

    *   比方下面失去的 roofline 曲线中，算子的计算访存比小于机器平衡点(通常将屋檐和屋顶转折点的横坐标称为机器平衡点)，所以能够初步判断该算子在该平台上次要 bound 在访存局部，平台的算力资源对于该算子来说还是有富裕的。并且能够依据算子的理论带宽跟机器的峰值带宽的比值，来评估后续访存优化的空间有多大。*   同时揭示一点，在获取算子 GBPs 的时候，咱们是拿到了算子理论产生的 ddr 访存量的，这个访存量能够跟算子输入输出变量总的内存占用大小做一个比拟，从而掂量出算子有多少反复访存没有被 cache 和寄存器 cover 住，而产生的对 ddr 的反复拜访。如果察看到 ddr 访存量显著大于输入输出总的内存占用，那么咱们就须要去扫视算子的访存逻辑是不是不够 cache 敌对，是不是有些反复访存能够通过加一些缓存逻辑来防止等等。

拓展思考

• 通过下面的步骤，咱们获取了 roofline 数据，这能够帮忙咱们判断以后算子在以后平台是计算 bound 还是访存 bound，以及绝对峰值算力和峰值带宽的 gap 大小。然而，单单依附 roofline 剖析又很难进一步具化瓶颈的地位和缓解的对策，比方访存 bound 的起因是因为哪一级存储的访存效率低下？计算 bound 是因为指令依赖还是某一类 alu 硬件资源缓和？

• 为了解决这些问题，mperf 还做了一些硬件参数探测、PMU 数据加工剖析、opencl kernel 的动动态代码剖析 (动动态代码剖析的性能，还在外部迭代开发中，尚未推到开源 repo 中) 等尝试，尽可能让算子性能剖析和优化更加有迹可循，或者说心智累赘更低。

  附：

  更多 MegEngine 信息获取，您能够：查看文档和 GitHub 我的项目，或退出 MegEngine 用户交换 QQ 群：1029741705。欢送参加 MegEngine 社区奉献，成为 Awesome MegEngineer，荣誉证书、定制礼品享不停。