深度学习ARM算子性能优化上手指南个人文章

GaussianBlur是一种线性平滑滤波。它的计算过程是：原图每一个点都和周边点进行加权求和，得到对应位置的输出，权重矩阵是kernel。以kernel_size=3为例，如图：

示例代码如下：

它可以由两个向量相乘得到：$\{0.25,0.5,0.25\}^T*\{0.25,0.5,0.25\}$。

接下来，笔者将以kernel_size=3的GaussianBlur为例，介绍一些常见的优化思路：

根据笔者的经验，性能优化的主要效益来自于算法层面的优化，这是从根本上减少计算量，所以第一步是考虑算法层面的优化。对于高斯滤波来说，它是一个可分离滤波，这意味着

前2步基本保证运算是必需且最少的，第三步就需要考虑提高数据级并行度。

数据级并行（DataLevelParallelism，简称DLP），主要手段是SIMD/SIMT，简单理解成一条指令同时处理多个数据。ARM上主要是使用NEON指令集/SVE指令集。受限于篇幅，以下的示例代码，只拿示例代码2中先计算前2行的行内卷积的部分做演示。

//示例代码3constexprsize_tstep=128/sizeof(float);//一条NEON指令能处理的数据长度为128bit,可以并行处理step个floatflaot32x4_tvload[3];//暂存load的结果，用于向量化计算float32x4_tk[3];k[0]=vdupq_n_f32(kx[0]);//k[0]={0.25,0.25,0.25}k[1]=vdupq_n_f32(kx[1]);//k[1]={0.5,0.5,0.5}for(inti=0;i

这一步是前三步的补充，主要是利用编译器再尝试优化一下。

简单理解循环展开(unrollloop)就是增大for循环的步长，让每一个迭代可以多处理一些数据，给编译器提供了更多调度的空间（比如指令重排，寄存器重命名，寄存器复用等）,同时也减少了分支判断的次数，从而提升性能。操作很简单，示例代码如下：

前面4步完成了计算的优化，还需要考虑访存的优化，同样是考虑减少重复的访存。

观察一下示例代码3，它的三次vld1q_f32分别load了

可以发现src0这个位置被重复load了3次。于是考虑引入一组向量head,body,tail去减少重复访存。示例代码如下：

简单总结一下：当算子是memory-bound时，可以考虑减少访存次数。比如：设计数据结构去缓存访存结果，减少重复访存。

当计算和访存都优化完，保证计算和访存都是必要且最少的，之后考虑引入多线程。

在示例代码2中，可以把整个height拆成若干段，每一段执行相同的代码，这样就可以开多个线程去并行处理。

前6步属于C++/instrinsic层面的粗调，这一步是汇编层面的优化，属于微调，性能优化应该遵循“先粗调再细调”的原则。当在C++层面想不到其它优化点时，可以考虑进行汇编优化。这里简单介绍一下，不过多展开。主要有以下要点：

需要注意的是:

这里的LDR指令(D-form)负责从指定地址load64bit的数据到寄存器里

*execlatency为3：它的执行需要3个cycle*execthroughput为1：一个cycle只能发射一条LDR指令*Dual-issue编号为11:可以从slot0或者slot1发射出去。知道这些信息，我们可以通过选择可以双发射的指令组合，达到掩盖部分指令的开销的目的。比如

于是可以用LDR（D-form）替换LDR(Q-form)，去和FADD(Q-form)做双发射，从而掩盖了LDR指令的开销。

例子3：cortex-a7是一个单发射，顺序执行的核心。那么主要是考虑根据指令的latency，进行指令重排，尽可能排满流水。

完成上述优化步骤后，如果性能还不达标，可以再考虑如下几点优化。

这里至少涉及两个方面。一方面是内存地址的对齐，不同硬件设备都有一些地址对齐的要求，比如ARMAArch64Load/Store指令要求访问的地址和所访问元素的大小（比如4字节）对齐，不然可能会触发对齐错误，带来额外的性能损失。另一方面是内存布局，比如NHCW,NCHW等，对于同一段代码，不同的内存布局，访存的连续性是不一样的。也会有自定义的内存布局，在一些情况下可以取得不错的优化效果。

这样的做法可以让编译器在编译链接时进行一些简单的运算，提前知道一些参数信息也有助于编译器的优化。比如可以把一些if判断的flag抽离，做为模板参数。

上述通过GaussianBlur的例子，介绍了一些可能的优化点，但这只是整个优化流程的一个步骤。

性能优化是一个不断迭代的过程，很难追求一步到位。一般的优化流程可以用下图表示：

为了得到一个正确的优化反馈，需要做科学严谨地benchmark。笔者认为benchmark至少需要考虑以下因素：

也可以考虑使用google_benchmark等benchmark工具。

做性能优化之前，往往需要先做一下profile，了解程序的热点（耗时最多的地方），观察有没有异常的开销（比如函数封装的overhead过大）。

可以使用一些profiling工具，硬件厂商通常会提供自己的profiling工具，比如x86上用intel的vtune，nvidia用上nsightcompute，arm上用armmap,android上用simple_perf等。

也可以手动加计时函数，比较核心代码的速度和封装后的速度，确定封装带来的overhead是否合理。