专栏首页奇点大数据支付宝如何优化移动端深度学习引擎?

支付宝如何优化移动端深度学习引擎?

1.背景

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

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都有运行速度的优化选项,打开这些选项大部分情况下都会帮你的程序速度提升不少,虽然这还远远不够,但聊胜于无。

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(内联汇编)。

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;

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的手机,电池不要随便爆炸,就可以支持。然而兼容性和可靠性的提升,不比开发过程顺利多少,需要解决很多工程上的问题。

6.更多

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

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

本文分享自微信公众号 - 奇点(qddata)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 算法之旅(1)——认识算法

    从今天开始,我将用100期的内容讲解各种计算机领域常用的算法和思路,以及优化方法,主要覆盖图论、模式匹配、快速查找、概率统计、聚/分类、神经网络、分布式算法等。...

    刀刀老高
  • 会打电话的AI背后:谷歌Duplex技术解析

    谷歌5月8日在加州召开了 2018 年度的开发者大会(Google I/O 2018)。在大会介绍的 Android P、Gmail、Gboard、TPUv3 ...

    刀刀老高
  • 深入了解Google的第一个Tensor Processing Unit(TPU)

    作者: Kaz Sato(谷歌云Staff Developer Advocate) Cliff Young(谷歌大脑软件工程师) David Patterson...

    刀刀老高
  • 什么是Java内存模型

    有一个关于JVM名词定义的问题,说”JVM内存模型“,有人会说是关于JVM内存分布(堆栈,方法区等)这些介绍,也有地方说(深入理解JVM虚拟机)上说Java内存...

    java架构师
  • 并发面试必备系列之并发基础与内存模型

    在 《Awesome Interviews》 归纳的常见面试题中,无论前后端,并发与异步的相关知识都是面试的中重中之重,本系列即对于面试中常见的并发知识再进行回...

    王下邀月熊
  • Java 多线程(3)---- 线程的同步(上)

    我们在前面两篇文章中分别看了一下 Java 线程的一些概念、用法和对于线程控制(开始、暂停、停止)等,并对其中的一些易错点进行了总结,如果你是对这些概念还是还不...

    指点
  • Java并发编程实战 01并发编程的Bug源头

    编写正确的并发程序对我来说是一件极其困难的事情,由于知识不足,只知道synchronized这个修饰符进行同步。 本文为学习极客时间:Java并发编程实战 0...

    Johnson木木
  • 学习C语言你所必须要了解的知识

    C 语言的发展方向 ? 20世纪80年代初,C 在 UNIX系统的小型机世界中已经是主导语言了,从那时开始,它已经扩展到个人计算机和大型机, 大部分软件开发商公...

    企鹅号小编
  • Tools-在线RTF合并

    之前小编写过使用SAS实现RTF合并,日前,小编的网站也上线了RTF合并功能,支持在线文件合并。合并效率远超SAS,基本不可同日而语。当然,在线合并RTF的原理...

    Setup
  • 20180811_ARTS_week07

    https://medium.freecodecamp.org/prototype-in-js-busted-5547ec68872

    Bob.Chen

扫码关注云+社区

领取腾讯云代金券