含代码 | 支付宝如何优化移动端深度学习引擎?
    2018-06-20    家大

阿里妹导读:移动端深度学习在增强体验实时性、降低云端计算负载、保护用户隐私等方面具有天然的优势,在图像、语音、安全等领域具有越来越广泛的业务场景。考虑到移动端资源的限制,深度学习引擎的落地面临着性能、机型覆盖、SDK尺寸、内存使用、模型尺寸等多个方面的严峻挑战。
 
本文介绍如何从模型压缩和引擎实现两个方面的联合优化,应对上述挑战,最终实现技术落地,希望对大家有所启发。

 

1.背景

 

由于移动端资源的限制,大部分深度学习引擎都部署在云端,移动设备获取到输入数据,经过简单的加工,发送给云端,云端服务器经过深度神经网络推断运算,得到结果并反馈给移动端,完成整个过程。

 

显而易见,这种交互方式有很多弊端,比如依赖网络,流量过大,延迟太长,更重要的是,云端服务器必须有足够大的数据吞吐能力,如果移动端请求量太大,超过负荷,容易导致服务器宕机,从而使所有移动端任务都失效。其实,现有的移动设备已经逐渐从以前的单核32位到多核64位过渡,计算能力和存储能力有了很大的提升,将深度学习引擎部署到移动端已经成为一个必然趋势。

 

然而,成功将DL引擎部署到移动端并非易事。运行速度,包大小,内存占用,机型覆盖,甚至功耗都是必须逾越的障碍。支付宝移动端深度学习引擎xNN是这方面的佼佼者,本文将回顾xNN移动端DL优化的方法和技术。

 

 

2.运行速度

 

大部分移动端处理器都是基于ARM架构,移动端完成深度神经网络推断的任务,基于CPU的方案是最基础的,也是最可靠的;基于GPU的方案存在兼容性/数据同步/overhead过高/接口不满足等问题;DSP的方案也会存在兼容性的问题; 最近,很多手机芯片厂商开始构建AI协处理器(各种TPU/APU/NPU),但离应用还需要一定的时间。下面我们重点介绍一下在ARM平台的优化技术。做优化有三部曲,如下:

 

第一部:充分评估的优化目标。如果算法原型太复杂了,花再多精力优化也是徒劳。针对DL业务,务必让模型充分精简,直到你觉得差不多了才开始下手,不然的话,嘿嘿。

 

第二部:确认运算热点。这离不开一些timing profile工具,如XCODE instrument, GPROF, ATRACE, DS-5等,熟练地运用工具,可以事半功倍。

 

第三部:贴身肉搏。下面有利器若干。

 

2.1.基于C/C++的基本优化

 

编译器很牛逼,GCC/CLANG都有运行速度的优化选项,打开这些选项大部分情况下都会帮你的程序速度提升不少,虽然这还远远不够,但聊胜于无。

 

书写高效的C代码。循环展开,内联,分支优先,避免除法,查表等等优化小技巧一定要滚瓜烂熟,信手拈来。本文将不再赘述这些基本技巧。

 

必须学会看得懂汇编,即便你不写,也要知道编译器编译出来的汇编代码的效率如何。这样你可以通过调整C/C++代码,让编译器生成你需要的代码。否则,一切浮于表面。

 

2.2.缓存友好

 

基于CPU内存子系统的优化工作很大部分都是在想如何高效地利用缓存(cache),尤其是图像视频处理这种大量数据交换的场景。几十年前,我们的老前辈就发明了主存,多级缓存, 寄存器用来弥补存储器与计算单元的性能差异,直到今天这个问题还没有解决(或许一直都不会解决,存储器和计算单元的设计思路是不一样的,高速ram的成本肯定是高的)。存储层次如下图,原理很简单,你想跑得快,只能背得少,你想跑得快,还想装的多,那就要多掏钱买个车。
                                

 

CPU-内存 子系统工作起来后,如果寄存器没数了,通过指令从L1 cache拿,L1没数了(Cachemiss),从L2拿,Cache都没有数据了,从主存拿,从主存拿的话, 也要分时间和位置,主存(dram/DDR)不同时刻不同位置访问的效率都是不同的。这里分享几个准则:
   

         
少用内存

 

尽量复用内存,不要随便地申请一大块内存。访问一大块内存意味着cache miss、TLB miss、dram切bank的概率都会增大,效率自然就降低。小块的内存反复使用,可以让CPU更加持久地运作,CPU运作占比越高,程序效率越高。要知道,一次cache miss导致的访问主存,在复杂应用下,可能有几十甚至上百个cycle的stall. 


连续访问

 

数据访问一般都遵循局部性原理,位置相近的内存被重复使用的概率更高, cache的替换规则也大多给基于这个原理来设计,跳跃的访问内存会打破这个规则,造成访问效率的低下。


对齐访问

 

主存和缓存的最小数据交换单元是cache line, 所以访问内存的地址最好是按照cache line的大小进行,这样可以保证最高效的数据访问。比如某台机器cache line大小为64Bytes,申请一个128Byte的内存区域,将它的开始地址放在非64Byte对齐的位置,如0x80000020,那么访问这128Byte需要3条cacheline的访问, 若放在0x80000040, 则只需要2条cache line, 一般通过多申请一点点内存,来避免这种不对齐,比如用posix_mem_align() 函数;更近一步,为了对齐访问,有时需要对图像的边界做一些padding的,比如 224x224的图片,我们可能会存储在256x224的内存地址中,保证在随机访问某一行时,地址处于对齐的位置。如:
                     

 

                                 

合并访问

     

如果反复的读写一段内存进行运算,效率上肯定不如“一次读取-多次运算-一次写入”来的更高效。比如,DL模型中,一般CONV层后面跟着RELU,BIAS层,本着内存访问能省则省的原则,通过提前分析网络的结构,可以将CONV层和bias合并,甚至将CONV+BIAS+RELU合并在一起进行运算,可以获得很好的gain. 比如:
                  
 

 

经过合并后,原来对memory的三读三写,变成了三读一写,速度杠杠的。


显式对齐数据加载

       

在ARM汇编中,可以显式的通知CPU,加载的地址是一个对齐得较好的地址。比如       

 

其中,“:128” 即是通知CPU, R1存放的地址是一个128bit对齐的地址,此时,CPU在向内存发出数据请求时,可以发出更高效的信号。如果R1不是128bit对齐的,执行这样的指令会得到一个地址异常,也就是LINUX中常见的 bus error。怎么保证R1是128bit对齐? 程序员必须知道R1对应的数据结构,需要事先设计好地址偏移,保证该指令被正确执行。并不是所有case都可以满足这个要求。


缓存预取

       

请设想,如果CPU正热火朝天的做计算,这时我们在后台偷偷搬些后面会使用的数据到缓存,下次使用时CPU就不用再去等数据了,效率不是就变高了吗?是的。缓存预取可以做这个事情,如:preload [R1, #256],  可以让CPU在继续执行后面的指令,并开始在后台加载 $R1+256byte位置的数据到缓存中。

 

但是,preload是一条指令,当你发出这样的指令时,需要知道,至少一个cycle浪费掉了,然后再考虑你预加载进cache的数据,是不是马上就可以接着被CPU 采纳。不幸的是,在手机实时操作系统中,可能多达几十甚至上百个线程嗷嗷待哺,完全无法保证预取的这些数据会被马上用上,系统中有大把事件是会让你的线程找地方歇息的,这种情况下,你预取的数据非但不能用,还可能被其他线程从cache中踢出去,白白浪费了一次主存访问。但是梦想总是要有的,万一实现了呢,总要试试才知道效果吧!

类似的方法可能还能举出一些来,但宗旨只有一个,在做同样的事情的前提下,别让你的CPU经常停下来等数据。

 

2.3.多线程

 

手机核备竞赛前几年搞得如火如荼,最近慢慢冷下来了,但也说明多核在运算上还有很大的优势。当然,多核的使用,会导致CPU占比和功耗直线上升,但在可接受的条件下,多线程优化带来的性能提升是最可观的。多线程的实现方法推荐使用OPENMP,接口丰富,编程简洁,用起来并不难,但需要注意一些细节。

 

线程开销

 

OPENMP会自动为循环分配线程,但并非所有循环都适合做多线程优化,如果每次循环只做了非常少的事情,那么使用多线程会得不尝失。线程的创建和切换会消耗一定的系统资源,线程调度有一定的规律,操作系统在没有高优先事件触发的情况下(中断,异常,信号量), 调度周期都在毫秒级别,如果每次线程执行时间没有达到一定的量,多线程的效果就会大打折扣。实际运用中,可以通过 #pragma omp parallel for if (cond) 语句来判断runtime过程中是否要启用多线程。

 

动态调度

 

默认情况,OPENMP采用静态调度机制,即将循环的次数平均分配给各个线程,不关心各个线程的执行快慢。如果某次循环运行比较慢或者循环次数不能平均分配时,容易出现负载不均衡的情况,这时就必须有动态调度的机制,动态调度可以根据线程的运行快慢,决定是否“互相帮助”。 OPENMP可以采用schedule(dynamic)来达到动态调度的效果。

 

                                  

同时需要说明的是,某些机型对于OPENMP的支持并不好,或者说线程的开销过大,这时,可能需要手动调整线程的负载和并行的方式。这些细节需要通过反复的实验来微调。

 

2.4.稀疏化

 

深度神经网络是个超级黑盒,人们把神经突触的权重找出来了,让整个网络可以完成特定的任务,但却不知道每根突触的作用是啥。实际上,其决定作用的很可能就只是那“几根筋”。我们的实验结果也是如此,大量的权重数据都可以是0,而整个输出精度相差无几。当发现网络中有50%甚至80%的数据为0时,那么针对稀疏的卷积和矩阵优化就显得非常重要了。

 

稀疏优化的重点是设计合适的索引方案和数据存放方式,如下图。

 

   

稀疏方案的应用,依赖不同的运算结构,如针对1x1卷积的优化,数据组织方法和3x3卷积就可能存在不同,不同的稀疏程度,得到的提升效果也是不同,需要不断地尝试各种方案和参数。

 

2.5.定点化       

 

大部分深度神经网络推断引擎,都需要用浮点精度来得到更精确的结果,这样paper上的数据才好看。但实际上,有些DL应用并不需要这么高的精度,即便是单精度浮点,也存在很大的冗余运算。以Tensor的1x1的卷积为例子,实际就是一个乘累加的过程,若使用单精度浮点存放数据,每个元素需要4个字节,而如果将数据量化到8bit, 只需要1个字节,节省3/4的内存访问量,这意味着在带宽紧张的状态下,性能提升会更加明显。下图体现了不同场景下定点化的性能提升收益(倍数)。

 

 

2.6.NEON及汇编

 

NEON 是针对高级媒体和信号处理应用程序以及嵌入式处理器的 64/128 位混合 SIMD 技术。它是作为 ARM内核的一部分实现的,但有自己的执行管道和寄存器组,该寄存器组不同于ARM 核心寄存器组。NEON 支持整数、定点和单精度浮点 SIMD 运算。经过良好设计的NEON代码,理论上可以比普通C语言版本快2-8倍。

 

NEON指令集分为ARMV7版本和ARMV8版本,寄存器个数和格式略有不同。写NEON指令有两种方式,一种是NEON Intrinsic, 一种是NEON Inline Assembly(内联汇编)。

 

本文主要是分享一些用Neon/汇编优化的经验,学习具体neon/汇编写法可以参考:

 

 https://community.arm.com/android-community/b/android/posts/arm-neon-programming-quick-reference

 

2.6.1.NEON Intrinsic vs Neon 内联汇编

 

大部分情况下采用NEON Intrinsic编程就够用了,NEON Intrinsic的好处也是非常明显的,首先,在armv7,armv8平台都可以跑,其次,代码简洁容易理解和维护,另外,编译器还会根据不同平台做代码重排;但是NEON intrinsic也有一些缺点,比如没有预取指令,分解Neon寄存器很麻烦,寄存器分配可能不高效,无法做显式的对齐加载,编译器可能会引进一些奇怪的指令,造成性能低下。

 

 

如果对某个模块的性能要求很高,编译器的输出不满足要求,这时候,就需要使用内联汇编;对于xNN中的核心模块卷积运算,都是通过内联汇编实现,性能比NEON Intrinsic提升10%左右。以下是ARM官方例子:

 

 

当然还有一种方式是采用纯汇编写程序,这不是所有人都能接受的。付出得多,收获也多,真正的高效的程序都是纯汇编的。相对编译器产生的代码,手工纯汇编的好处还是非常明显的,比如精简的栈内存,高效的寄存器利用,充分的流水线优化等等,有一种一切尽在掌握的快感。

 

但是,大部分情况下,用纯汇编写程序花去的精力,完全有机会在其它地方去弥补。所以这种方式适合追求极致的同学。

 

2.6.2.会写NEON/汇编很重要,构思好的实现方案更重要

 

NEON指令比较丰富,实现同一个功能有多种指令组合,除了理解指令的本身的作用之后,需要合理组织数据,使用更高效的指令来实现既定功能。

 

举个例子,实用实现单精度浮点矩阵乘法 sgemm中的 C = A * B + Bias,为了简单起见,假设矩阵的维度是2的幂。如 Dims(C) = 512x512, Dims(B) =512x512, Dims(B) = 512x512, Dims(Bias) = 512x512;  

 

代码1  :  C语言的写法是:

 

 

运行时间是: 1654689us  (小米5 snapdragon 820,下同).    

 

为了构造SIMD,我们将4个C的元素同时输出,如:

 

 

从而产生代码2,这是初步的NEON写法:

 

    

运行时间:633551us

 

考虑到数据的重复加载,可以多取四行,一次输出4x4的block, 这样可以省下接近3/4的数据读取,如

 

 

 

 

从而得到代码3:

 

 

运行时间:367165us

 

进一步,我们发现矩阵B的取数不连续,每次只取4个float, 远不到cache line (64Byte),相当于cache miss有3/4是有可能被优化掉的,存在很大的浪费,所以对B的数据做转置,转置的过程可以和实际代码结合,减少额外内存拷贝;同时,我们将Bias的作为sum的初始化值, 减少一次写操作。于是得到代码4:

 

    

运行时间是:60060us

 

最后,按4x4的block进行循环构造,然后用OPENMP进行多线程化,得到代码5:

 

 

运行时间25178us

 

上面四种NEON写法的运行速度增益分别是:

 

        

代码5肯定还不是优化的终点,通过数据重排,4x4的转置部分还可以省掉;cache的优化还可以更加细致;4x4的块是否是最优也有待论证;最后,还可以祭出汇编大杀器,性能还能再上一个台阶。

 

sgemm的优化版本还可以参考nnpack/eigen等开源库。实际代码中,需要处理各种维度的情况,代码远比上述要复杂。

 

3.包大小

 

移动端的资源紧张,不仅仅是指运算资源,app大小也是商用DL引擎一个重要指标,更小的包大小意味着更快的下载速度,更少的app下载流量。app大小的压缩包括很多方面,这里我们只针对库文件的大小精简,做一些经验分享。

 

3.1.编译优化

 

编译器有针对大小的编译选项,比如GCC的-Os, 相当于可以同时打开-O2的优化效果,同时精简生成目标文件的尺寸,生成目标代码后,链接成动态库的时候,可以通过strip命令,去掉多余的调试代码。这些是最基本的优化。针对IOS, 可以通过XCODE下面方法做精简:

 

  • BuildSettings->Optimization Level,XCODE默认设置为“Fastest     ,Smallest”,保持默认即可

  • Build Settings->Linking->Dead Code Stripping 设置成 YES

  • Deployment Postprocessing 设置成YES

  • Strip Linked Product 设置成YES

  • 工程的Enable C++ Exceptions和Enable     Objective-C Exceptions选项都设置为NO。

  • symbols hidden by default选项设置为YES。

  • 所有没有使用C++动态特性的lib库(搜索工程没有使用dynamic_cast关键字) Enable C++ Runtime     Types 选项设置为NO。

 

上述配置,在IOS设置输出目标为release时,XCODE会帮你自动打开一部分配置。同样的,在Android NDK编译,在Application.mk中配置OPTIMIZE=release,NDK会帮你做绝大部分的优化工作。

 

针对资源紧张的嵌入式设备,ARM提供了thumb/thumb2精简指令集, 相当于,同样的指令,同时有 16bit 和32bit 两套指令,使用 -MThumb选项可以让编译器优先编译出16bit的指令,在执行时通过内置的译码器,将指令转换成32bit的指令,这样既可以精简代码,还可以保持原来32bit指令的性能。

 

针对动态库的发布,还可以通过Invisible Symbol的方式,将不需要的符号隐藏起来,省下目标库文件中符号表的表项,如果你的代码有大量的函数,这会是不小的提升,试试看,说不定有惊喜。具体写法是:

 

这样就ok了,简直是物美价廉!

 

3.2.代码精简

 

以上都是一些常规的缩小库大小的方法,实际上,针对DL模型的特性还可以进一步精简库大小,比如包括:

 

  • 库依赖简化- 大部分开源引擎都会依赖C++ STL库,如Caffe/Tensorflow, 如果要做到极致的精简,需要将复杂的C++属性去掉,这样可以依赖更加紧凑的stl库,甚至不依赖stl.

  • 功能裁剪 - 删除不常用的layer,删除不常用的代码分支,或者Layer组件化,用时加载,都可以减少基本库大小;

 

 

3.3.模型压缩

 

深度学习模型的size,小到几M,大到几百M,如果不做压缩,根本是不可想象的。模型中的大部分数据是神经网络的突触权重,存在有巨大的压缩空间。比如, 支付宝xNN团队提供的xqueeze工具,可以让深度学习模型压缩比例达到几十甚至一百倍。压缩技术包括神经元剪枝 (neuron pruning)、突触剪枝(synapse pruning)、量化 (quantization)、网络结构变换 (network transform)、自适应Huffman编码(adaptive Huffman)等等。具体实现可以参考一些主流的Paper。

 

4.内存精简

 

内存使用也需要精简,低端机型有可能只有1G甚至512M的内存空间,再复杂的应用场景下,经常会不够用。精简内存,可以一定程度上缓解内存不足引起的闪退;另一方面,使用更少的内存也有利于推断速度的提升;

 

具体到DL推断过程运行时存在很大的内存冗余,比如:

 

实际上,推断过程中,大部分输入层在做完运算后,可以被马上释放,所以完全存在复用内存的可能性。

 

支付宝xNN 设计了一种称为MPool的内存管理机制,结合深度学习推断的过程,MPool 通过分析网络结构,在内存充分复用的前提下,计算出最小的内存使用量,在开始推断前提前申请足够的内存。

 

 

MPool有如下几个优点:

 

  • 避免推断过程中反复申请释放内存;

  • 内存申请全部集中到初始化过程,避免推断过程中出现内存不足导致的推断失败,从而改善用户体验;

  • 充分的复用可以提高的内存访问效率,对性能提升也有一定的帮助;

 

采用MPool结构的DL引擎,运行主流模型,内存占用降低达到75%以上。 

 

5.兼容性与可靠性

 

商用软件,兼容性和可靠性是很重要的指标。举个例子,支付宝xNN在春节扫五福活动中,机型覆盖率达到98%以上,基本上只要是ARM based的手机,电池不要随便爆炸,就可以支持。然而兼容性和可靠性的提升,不比开发过程顺利多少,需要解决很多工程上的问题。

 

举几个例子:

 

为了在支付宝app中部署xNN,需要兼容app中的stl版本;

为了兼容旧版本的Android, 必须使用较旧一点的NDK版本和API, 否则会出现一些数学库的兼容性问题;

为了保证连续多次运行内存不泄漏,需要在不同android/ios版本的上做疲劳测试;

为了多任务并发,需要做互斥;

为了兼容受损的模型文件,需要做多层次的模型校验和兼容。

……

 

这样的例子还有很多。总结一句:出来混的,迟早要还的;代码中的任何瑕疵,最后总会被爆出来。


6.更多

 

基于CPU的实现方案,面对复杂场景/强实时性应用,还是力不从心的,毕竟CPU资源是有限的,永远都无法预测用户部署的模型的复杂度,也无法预测手机后台运行了多少程序;异构化也是重要的优化方向,采用DSP/GPU来做推断可以大大降低功耗,同时还可以提升推断速度,DSP/GPU方案面临的问题是兼容性比较差,每一个款手机都有可能不同,所以需要做大量的适配工作。

 

最后,模型安全也是需要考虑的方向,模型文件包含了用户的知识产权,对模型文件适当加密和隔离运行,可以有效地阻止模型被破解和盗取的风险。

评论加载中...