华为鲲鹏专家解读：90%代码如何移植到鲲鹏平台

摘要：探讨一下软件移植到鲲鹏平台过程的原理，以及软件工程的相应的过程。

Linux环境下跨平台软件移植过程当中，须要开发者阅读代码、手工修改、反复编译和调试，移植周期长，效率低，那么如何改进周期长，效率低的问题呢？

基于此，来自华为智能计算专家张汝涛带来了“90%代码如何实现自动移植到鲲鹏平台”的主题分享活动，他主要从鲲鹏开发套件实现基于C/C++软件的高效代码移植，加速开发者实现跨平台软件移植两个层面进行分享。如下分享的速记内容：

今天要讲的主题是关于软件迁移这一件事，是一个久远的话题。由于但凡是牵扯到切换平台、CPU架构的变化，甚至一些语言版本的升级，咱们均可能会面临到一些软件迁移的问题。今天一块儿来探讨一下软件移植过程的原理，以及软件工程的相应的过程。

鲲鹏在软件移植的过程中，如何去帮助开发者去提高效率，如何把鲲鹏沉淀下来的，把华为沉淀下来的软件开发以及一致的经验如何反馈到开发者，让开发者可以加速软件开发的进度，下降成本。咱们推出咱们鲲鹏的开发套件，帮助用户作软件的移植，以及作基于鲲鹏平台的性能加速，今天主要是这样三个内容。

一提到软件移植，我不知道你们有多少是作了比较底层软件的，作底层软件的话，你们可能会用到一些汇编，C++加这样的底层语言。用到这种底层语言，它是会和机器的硬件架构强相关的，当你在从一个平台切换到另一个平台的时候，这些强相关的语言势必要进行一次，跟咱们所采用的编程语言以及移植的平台环境强相关。

当咱们用汇编代码或者是用这种编译型语言的时候，咱们就会面临着一些移植的问题、一些挑战。有些问题可经过编译器能解决，有些问题特别是一些低阶的代码或者底层的代码，咱们就会可能要面临着必需要手工去查手册，而后去把它相应的去转换到新平台所使用的机器码。

这里就列出咱们鲲鹏处理器和x86处理器的一个指令差别，例如一个简单的两个数相加，两个int型相加的这样一个简单程序。经过GCC编译完以后，咱们去经过OMGD，咱们就能看到指令的具体的格式形式以及相应的对应的汇编代码。这里能看到对x86平台而言，由于x86是CICS指令是复杂指令集，鲲鹏是彻底兼容Arm64架构的，是华为自研的vinic，指令集也是和Arm64副精简指令集是彻底兼容的。

其实所谓的经限指定集和复杂指令集的区分是从上个世纪的70年代开始的，IBM曾经作过一个研究，就是关于说CPU如何去高效的运行，而后他们会发现可能有些经常使用的指令或者是程序代码，当时背景下经常使用的程序代码，可能经常使用的和不经常使用的有很大的差别，当时又由于IC的制程或者工艺或者器件的设计水平没有如今这么日新月异，因此就会想如何去把CPU从硬件设计上简单一点，从软件上高效一点，因此他们就提出了精简指令集这么一个概念，其最大显著的特色就是它的指令宽度就是长度。咱们说的指令长度，是相等的，也就说每个指令这个位宽是相等的，那么每一个指令执行的SICO几乎也相同，就是他把很繁杂的事情作的尽量的简单，而后用不少简单的操做去完成一件复杂的任务。

从相反的复杂指令集的角度，咱们看一下x86下面的复杂指令级，它每个指定的长度是不一样的，也就是说像这里列举的mov和add这两个指令，它的机器码、指令码是不一样的，长度是不一样的，势必会形成咱们IC器件的解码器，以及包括咱们真正的到软件流水操做上处理的步骤是不同的，也必然会致使咱们每条指令的执行的周期是不一样的，可是这样也有一个好处，就是我一个指令就能完成一个比较复杂的事情，尽管说个人指令可能会变得很长，可是我一条指令能完成一比较复杂的事情，对上层的程序员来说，可能就便于理解或者是相对的会容易理解一些。

这就是精简指令集和复杂指令集的一个简单背景，在反汇编下来的x86指令集和鲲鹏指令集的汇编代码上，能够看到操做指令是彻底不一样的，计存器的命名也是彻底不一样的，在x86的平台上，有16个通用寄存器。这里讲的是x86 64模式下，有16个通用寄存器，浮点计存器，根据咱们支持的MMX技术、SSE或者是ABS技术，x86平台最多能够存在32个浮点寄存器。

反观鲲鹏平台，由于它是和Arm64指令兼容的，因此指令集要事彻底对照，因此从这个角度来说，鲲鹏平台有31个通用寄存器，除了这31个通用寄存器之外，还有一些状态寄存器或者是一个站寄存器。那对应到浮点寄存器，就有32个这样一个叫作ASMB的的advances单指令多数据这样一个寄存器。鲲鹏有32个寄存器位，位宽是128。这一点是和x86 64平台是有差别的，好比说如今x8664，它若是支持ABX512的话，它的位宽是500 12比特，从这个角度上，是一个硬件器件差别是很是明显的。

而后从反汇编的角度来看，你们不知道有没有注意到x86平台上有一个mov指令。从第一行咱们能看到从寄存器、rbp一个mov的存储数据，到EDX这样一个寄存器，作一个从把变量从内存里漏斗进来。一样的一件事情在上面的鲲鹏处理器平台上寄存器的指令就变成了LDR和而后下面固然加法仍是有add的，而后存储的时候对于x86来说，又是从寄存器mov到了内存力，可是对于鲲鹏平台它是用一个str指令，因此这也反映出了一个risk指令的特色，也许是第2个特色，咱们姑且这么叫，它是用一个load stall这样一个模式，也就是说在鲲鹏处理器平台上不支持内存到内存的一个直接访问，必需要通过一个寄存器做为桥接做为一个中转。

这一点是和x86指令复杂型指令集不一样的另一个地方。还有就是在x86这个平台上，它的内存访问的模式很是多，对于公共平台上就没有丰富了。这个就是以一个程序为例，简单列举一下，从CPU的角度来看，一样是一段C代码，CPU他作了不一样的事情，执行了不一样的指令，通过不一样的周期不一样的运算之后，它会输出最终计算的一个结果。固然从这个角度来说，从这段程序两个平台是没有任何差别的，除了指令上之外，执行结果是不会有任何变化。

但这里侧面反应出来，由于指令集不同，因此对于C，C++这样偏底层的这样一个语言来说，虽然它是个高级语言，可是必需要考虑一个平台差别，在平台切换的时候，甚至在平台这个软件的编制过程中，就要考虑一个平台兼容性，因此要养成一个良好的编程习惯。

跨平台移植软件要面临的很多问题，由于软件移植自己就是一个工程性问题。这里一般第1步来说，若是说咱们决定从x86平台迁移到鲲鹏平台，就要去判断一下这个软件迁移值不值得，困难有多大？一般目前的经常使用的作法就是把x86的平台，相应的软件包拿下来，而后去看看它的依赖性关系。这个是什么意思呢？就是咱们看看这个软件，若是跑在x86平台上，它依赖哪些第三方组件？这些第三方组件在你这个目标平台上存不存在要作一些这样的判断。这种判断一般都是这个平台之间的反反复复的安装、运行，而后根据系统报出来的错误去一个个来排除，因此这都是经过人工来完成的，比较费劲。若是有移植经验的同窗就会以为比较费劲，有些事情很繁琐琐碎，一个不当心就错了，可能还找不出来缘由。

当你解决完第1步编译的过程的这个问题以后，你可能会还碰到一些跑过，结果新平台上出现了function fault，功能性错误咱们就很讨厌了，可能性缘由比较多，有的是自己软件逻辑有问题；多是第三方组件的APA跨平台兼容性有问题；多是系统自己支持度也有问题，这个就是影响因素比较多。这样就须要移植以后，技术人员去相应定位。定位对每一个人对相应的工程人员来说，专业技术要求会比较高，也存在着一个反复编译、反复调整、反复验证，这个过程成本会很高。

当完成了功能验证以后，跑过一些基本测试之后，感受这个软件在新平台上能够刊用了。你可能会面临的一个性能的问题，当你用在工做环境、生产环境的状况下，由于生产环境的软件都但愿用最小的硬件跑出最大的性能，而后跑出最高的一个性价比，这时候都会对软件性能上的需求，对它有要求。这个时候咱们就会不得不去采起一些方法，例如用一些商业软件也好，或者一些开源的软件命令也好，去分析这个软件的瓶颈究竟是哪里有问题，是系统有配置的参数有问题，仍是我软件自己逻辑有问题。

因此这三步是咱们在华为的软件这么多年的开发过程中积累下来以为比较重要的三步，对咱们软件的质量、移植的质量是有决定性影响的。这三步也同时对于任何人来说，可能都不是一个能轻松逾越的几个障碍。

对于咱们软件移植这件事情，一般咱们讲的是对于编译型软件会面临这样的一个困难，对于解释性反而比较轻松，为何？好比像咱们如今经常使用的一些Java的或者Python的，甚至一些GOD这样一些软件，咱们的依赖是什么？依赖的是语言所提供的虚拟运行环境，甚至是一些像Java提供的Java虚拟机GUM，咱们只须要选一相应平台的GUM安装，咱们就能把底层的全部差别性都屏蔽掉。

这个软件只根据运行环境去跑，一般是没有问题的。对于像C,C++,GOD这种的，可能做为编译，甚至说可能会调用C,C++加这种组件的这种软件，咱们就须要C,C++这种代码进行移植，能够分这么几种状况。

第1种是开源软件，对咱们一般是和社区进行合做，让社区去支持空洞平台，或者是支持M64的平台，这样咱们就一劳永逸的解决问题。而后对于自研软件，对于有些SB用户会开发者资源软件，他不能开放代码，咱们就须要进行商业合做，去引导客户去移植到咱们鲲鹏平台上。

对于商业B软件是最典型的，好比说像微软的一系列软件，或者是Oracle的软件数据库，咱们不可能去得到源码，去推进他们和咱们中国的软件界合做也非易事.这个时候你只能找到要么是合做，要么就是找一个替代方案，对吧？若是实在是又不能替换用户的业务，又不能去修改，咱们就可能不得已采起一个鲲鹏平台和x86进行一些混合部署，这是一个软件部署方面的策略。

还有一种就是对于咱们经常使用的windows平台的一种系列开发，咱们也知道windows虽然一年多前可能说要支持Arm64这个架构，但实际上到如今为止他也没有宣布。其实商业上的考虑或者是其余的因素可能都考虑的比较多，尤为是这样一个大致量的公司，可是对于windows平台就是说咱们进行有限度的在开元生态里面进行有限度的支持，好比说像微软的C shut，其实他的call3.0已经开源了，已经在Arm平台上可以用起来了。换句话来说，咱们也能够在鲲鹏平台上基于call3.0支持C shut。对于鲲鹏软件移植的过程，能够把它分解为这样几个步骤流程，其中最重要的就是所列到的第2步第3步以及性能达标分析这一步，咱们如今提供了相应的每一步提供一些的辅助工具去帮助客户进行用户开发者进行分析进行移植。

其中的二进制文件依赖扫描，是咱们去提供了一个工序软件进行软件安装、依赖库的扫描和软件运行依赖库的扫描。根据咱们长期积累的有一个兼容性清单，这个兼容性清单覆盖了市面上大多数流行的以及经常使用的OS以及相应的版本，还有相应的GCC的版本，对于移植的第二阶段，像移植修改C，C++原码，咱们也一样提供了一款工具去作C，C++源码的分析，这个分析主要是集中在这样几个方面，集中在汇编代码、边选项，还有宏定义，还有built in函数和编辑提供的built in函数和attribute，而后去重点检查用户的Makefile和CMakeList。若是用户软件是用make构建的或者CMake构建的，咱们能帮助去发现一些，识别一些移植中须要修改的地方，同时咱们会给出移植修改的建议。

当移植完成以后，咱们会提供一个性能分析的工具，去帮助用户去check这个软件是否是可以达到工做这样一个标准，也就是说check它的性能指标，咱们会去进行系统性的性能分析，也会去作软件级的热点定位分析。而后在此基础上咱们会给用户提供一些华为所积累下来的认为比较有效的一些软件优化的方法，作一些好比说终端版壳操做，甚至一些其余的软件修改的这样建议，这个就是咱们今天要介绍的三款软件，经过这三款软件咱们就能比较方便的或者比较高效率的完成C，C++代码，从非鲲鹏平台向鲲鹏平台的这样一个迁移值的过程。

在C，C++软件移植的过程中，咱们要着重考虑三个方面的问题，第1个问题是软件构建文件的差别。这里面举两个例子，一种是我们这个方案里面，咱们可能在x86平台上常看到一个叫-M64的这样一个知道编译选项的option，这个含义，其实是说要把我这个软件生成成为64位模式的。是分红64位模式的，咱们编译目标代码的ABI。实际上在鲲鹏平台上，咱们能够用相似的，咱们能够用-mabi=lp64去来替换，固然若是安全的状况下，加上-FPIC就生成一个flowting的address，来屏蔽一些底层的相关依赖性，这样子就能达到一个编译选项M64的一个替换。

还有一个就是对应Arm指令集、SA的这样一个替换，咱们经常使用的可能会见到一些-march的这样一个参数，在x86的平台上提供了多达二三十种架构平台，从intend到AMD的各类各样的，Arm平台来讲，就相对简单一点，咱们只须要去选用咱们鲲鹏平台，你CPU所支持的兼容Arm的架构。咱们鲲鹏920，咱们进入的是AArm8.2-a这样一个架构。若是这些版本比较新，好比说9.1以上的，咱们就能够去选用-mtune=tsv110。这其实是咱们泰山微内核110这个型号这里面会在Gcc内部进行了咱们提了一些措施，针对架构作的一些的public的tune优化，可以提供一个相对较好的性能。 性能增长，听说有5%~10%的性能提高。

接下来第二部分就是C，C++原码的移植，这里面也举两个例子，第1个例子是这个是基本数据类型，尽管说咱们鲲鹏平台支持的是LP64，而后这个x86平台也支持LP64的这样一个规范，可是实际上你们在某些细节定义上仍是有区别的，虽然字符宽度，好比说对x来说都是8字节，可是x86他这个x是有符号类型的，可是对于咱们鲲鹏平台，咱们用是无符号类型的，但这块的改动咱们就能够经过修改makefile里面，加一个参数，加上-makefilex，去把默认的无符号的x定义成有符号的x，这样就能保证C代码逻辑，关于x操做上不会引入歧义。

第2类问题就是咱们编译器当中提供了多达数百个的这个宏定义，能够被咱们C，C++软件识取，好比说咱们用GC的话，咱们能够在C，C++的软件里面，原文件里面直接去使用相应的宏定义，这个宏定义在编译的时候可能会咱们的编译器直接作环境变量的check，而后直接设置了相应的正确的值，跟host环境相关的。我这里指编译和运行在同一款机器上，咱们不讲host和target相异的状况。这个时候对于相应的软件，咱们就可能须要区分一下宏定义，好比说像这里x86 64，显然一看就知道他是支持x86的，不可能在咱们鲲鹏平台上运行，这时候咱们就会建议用户去修改用户代码，用预编译的方式作软件范围的定义隔离，很显然对于咱们鲲鹏平台，咱们经常使用的关键字就是aarch64或者是Arm64，这样的关键字去作软件逻辑的定义，除了这些之外，包括BBC都有各自的架构定义关键字。

第3类问题就是咱们汇编代码的移植，这也是最头疼的一块，由于x86平台若是细算的话，他将有2100个不到的汇编指令，鲲鹏平台由于兼容Arm64，咱们有1000出头，1100不到，这样一个汇编指令，其实这加起来3000多条指令，若是你们想把它分清楚，那是很是痛苦的。Int的相应指令集的手册有4000多页，Arm相关指令集的手册有7000多页，纯英文的文档你们读起来确定会崩溃的，因此在这里面汇编代码的移植，这是一个难点。

汇编代码在咱们的软件过程当中表现有若干种形式，第1种是咱们纯粹的就用Asm关键字去写汇编代码，第2种是咱们用built in函数作一些替换，好比说这里举个例子，像GCC里提供了built in的CRC的32计算的一些加速指令，咱们能够去寻找鲲鹏平台上的相应的指令去进行替换，好比说像x86平台上用到的预取的指令，咱们也能够去找到鲲鹏平台，上的built in函数去作替换。接下来还有第3种，就是咱们可能会用到的Intrisic。Intrisic其实是在jcc里提供的像C语言能够同样去使用的汇编函数，引出这个Intrisic是在x86平台上和Arm64平台，就相差很是的大。

在x86的平台上Intrisic总数总数将近达到7000个，7000不到，而后在鲲鹏水平上相差就差的比较多，远远少于这个数，为何？这是由于在x86平台上它支持的指令集比较多，他本身通过二三十年的演进，对吧？他有mx的指令集，有SSE的指令集，还有AVX，AVX也分了128比特的,256以及500 12比特的三种。 每一种它对应的Intrisic很是的多，因此移植的数量是很是大的。在这个里面咱们能够找到一些，好比说对于一个28比特的操做进行一些对应，能够作一些替换。

针对上面提出的这些问题，好比说咱们C，C++刚才提出这些问题，咱们就提供了这样几个工具，咱们这里提供了分析扫描工具，代码迁移工具。分析扫描工具，就是识别咱们软件移植的依赖性，而后去帮助用户作兼容性的排查。而后第2个提供代码迁移的工具是作源码的构建工程工程构建文件，还有C，C++原码以及汇编代码的扫描移植指导。第三个工具就是性能优化工具，咱们刚把软件移植到鲲鹏平台以后，咱们须要去用这个工具去分析性能，去发现热点，咱们也提供了基于鲲鹏平台的一个加速库这么一个概念，一个组件。 这里面就提供了一个软件硬件协同加速用户应用的一个方式。

好比说咱们这里优化了GDPC基础运行环境，咱们优化的压缩、加密、加解密，包括一些数学计算这样一些开源的或者是三方的组建，咱们优化了一些IPP信号处理的一些程序功能提高，就是用咱们软硬结合的方式极大提高了性能。这里面咱们大体分析的一个流程，咱们会在分析扫描里面，咱们把用户的软件上传到咱们的工具环境下，咱们工具环境就会分析用户X86平台上软件的安装包，好比说这里的RPM包还有一些JAR、Java类的程序，包括一些压缩包，咱们就会去扫描识别里面软件包内部以及软件安装路径内，包括咱们压缩包内部的集成的，好比说这些SO件、二进制文件，去检验它是否在鲲鹏平台上不一样的操做系统上是否支持，去反馈用户一个一致性的分析报告，会逐个告诉用户SO是否兼容，不兼容的话怎么去处理？咱们会提供连接是原码的值，这个是源码级的连接，或者是提供移植文档方式书的这种连接，都会在咱们报告里提供出来。

咱们这个工具提供了两种工做方式，一种是咱们经过命令行的方式，下面这种形式经过参数输入，一种是经过这种外部方式，咱们在作了安装包的依赖性分析以及原码的扫描以后，会给用户产生一个移植分析指导的报告，这个报告是提供CVS的格式或者是HDM的格式，用户能够去下载，里面就会详细罗列出哪些依赖库，哪些二级制文件须要移植，而后哪些C，C++以及汇编代码，须要移植规模有多大？ 会给用户呈现一个移植的工做量，好比以每个月为单位提供一个工做量。

计算标准，用户是能够本身输入的，好比说你的编正能力强，你一个月C,C++代码，你能够完成800行，汇编代码你能够完成600行，对吧？若是你的移植能力有限，有的编码能力有限，技术成本有限，你能够把它设置成好比说我C,C++代码一个月300行，汇编代码100行，它就会根据不一样的标准，计算出你移植工做量，作工程技术上的第1步，第1部信息掌握。

这里就列出了咱们主要的功能，前面我已经基本赘述了，就是SO文件的检查，构建工程的检查、源文件的检查，评估一致性，而后进行工做量评估，两种方式，外部方式和命令行方式。

经过这个工具，咱们就能够拿到软件移植的工程量的第1手资料，而后决定是否移植。当决定极值以后，咱们就能够用代码迁移工具去作进一步的分析，代码移植工具主要是分析了用户的源代码，仍是同样，他着重分析的是makefile，C，C++的源码，就包括咱们这里的编译器提供的宏定义，而后用户自定义宏，还有built in函数，Intrisic，还有汇编代码，咱们分析完这些内容会提供一个详尽的移植指导，这里面就包含makefile怎么修改？C，C++代码怎么修改？ 然汇编代码，咱们怎么去修改？

这里咱们只是给移植建议，咱们并不去修改用户的原码，用户能够参照着相应的输出咱们这里输出的一致报告，去用GTDF的方式，你们去作一个这个对比，而后去把它在工具界面之外用第三方的，好比说用其余的编辑工具把它完成修改。那么这一页咱们就列出了咱们代码移植工具的一个大体工做流程，一样咱们也是外部方式和命令行方式两种方式，方便用户作选择。咱们分析用户的源码构建工程，还有公共建工程配置文件，还有C，CC+加的源码或者是汇编源码，而后给出移植知道，那么对于源码的变化，咱们会提供对比的方式显示，像这里举的例子就是左边第1点是咱们要改哪些文件，就是修改文件列表，第2类就是咱们要原文件是什么样子，第3类就是咱们建议修改为什么样子？

这是咱们软件移植工具所能提供的能力，咱们C，C++，咱们这里仍是针对C，C++目前为止C，C++的这样编译型语言,去作了建议值，而后咱们要有源码，没有源码，也就谈不上移植了。

前面已经讲了，咱们如何去作软件依赖性的分析，经过华为开发套件去作软件依赖性的分析，以及作C,C++的移植，咱们在完成移植以后，咱们会在生产环境上去跑咱们这个软件，咱们可能会去作性能分析，这时候咱们就会提供一个咱们叫作分析的一个工具，这个工具主要是帮助用户去作软件性能定位，好比说你有些性能瓶颈或者有想继续优化，咱们这里提供了一些手段，这里对于这个工具咱们能够帮助用户去分析处理器相关指标，以及看到调度的一些信息，包括外设的信息，包括CPU、磁盘，甚至网卡、短时间性的数据，去帮助用户分析C，C++或者是Java程序这样一个性能指标。

咱们Java类不是说把GBM当成一个进程，咱们是看到GBM内部的，仍是有必定做用的，仍是比较有用的。咱们会把这些数据通通的分析起来，而后经过咱们本身定的定义的数学模型进行分析，去看到用户的软件性能瓶颈，好比说是资源竞争的问题或者是调度的问题，甚至说好比说有一些bug致使了一些次循环等等的，咱们提供了多种的方式来呈现这样一个结果。好比说咱们经常使用的这种火焰图的方式，咱们这里可以提供比较直观的可视化方式，帮助用户去看本身的软件里面到底有没有性质上的问题。

这个是咱们这里是罗列一下咱们目前性能分析工具可以提供的性能指标，咱们可以看硬件器件相关的，好比CPU、内存、磁盘、网卡、系统级的，咱们也能看这种线系统调度以及的好比说进程、线程，还有彼此之间的切换，或者是资源的争抢，锁这样的一些关键变量的这样一些性能分析先行指标，咱们也提供了一个基于火焰图、基于代码逻辑的深层次检查，可以提出用户代码的真正的开销，大的地方在哪里，对应的代码对应到源码。

经过这样一个手段，咱们就能帮助客户比较快的去帮助开发者比较快的定位本身的软件，编译形软件的瓶颈。，当定位到软件瓶颈的时候，咱们会提供一些附加的能力，好比说这里咱们就提供加一个叫加速库，咱们软硬结合的加速库帮助用户去优化代码。这个缘由是什么？这缘由主要是由于咱们鲲鹏是一个sock，咱们是一个片量系统。

除了泰山内核，以及多达48甚至64的内核之外，咱们还提供了一些额外的能力，额外的一些引擎，这些加速引擎就能够支持，好比说压缩LZ77的这种算法，还有加解密的，好比说非对称的，还有对称加密的，包括一些经常使用的变加解密的这样算法，好比说DH编码等等。

咱们还支持了好比说存储用到code等一些这样一些经常使用的软件算法，咱们把它运化成加速器，这种压缩用起来很是简单，就跟咱们用一个外设同样，咱们只须要从华为的网站上去获取相应的硬件驱动代码，把它安装上以后，咱们就能够像一个正常的外设同样去使用它。

固然了你要使用咱们提供的一些API的话，可能还要遵循一些,好比说咱们要提供给用户手册，用户可能要去修改一下本身的源码，好比说可能原来掉的一些是软件的这样一些函数，或者是三方组建的API，这时候可能去要用加速器的话，就须要根据API修改我相应的这个代码逻辑，但这个代码逻辑只是存在于API层面。

这里举个例子，好比说咱们这里集成了一个叫RC的加速的引擎，是用来计算finish加密的，咱们支持1024~4096，4种：1024 2048 3072 3096，4种密钥长度。咱们在咱们加速器引擎里面，咱们是经过一个用户态的来libry去作一个隔离，对上去隔离用户的，好比说开源的第三方软件，好比说这里贴到open SSL的的API，咱们去对接open SSAPI咱们也能够把API暴露出来，直接给用户的APP去使用，在libry下层的就是咱们IC引擎的相应的驱动，用户能够彻底不用知道下面细节是如何实现的，可是咱们经过只要使用咱们正确调用鲲鹏RC的提供的用户libry，就能够去使用咱们加速器的硬件计算能力，极大的加快了RC的计算。

其实咱们也知道RC计算若是用CPU算的话，那是至关费时费力的。好比说一个像x86的一个中高端的一个call，可能它每秒钟只能执行720次左右的一个RC2048的计算。可是你要用到了鲲鹏920提供的RC计算引擎的话，计算量将是大幅度的提高，也就是说，我能够把本来用来计算RC的这些CPU彻底释放出来，跑个人业务！在一个芯片内完成这样业务，就会对用户来说就会提供另一个选择，我不须要去买某些PCIE的插卡，我直接去用软件的方式来提高个人软件性能，达到一个比较简单的提高性能的一个方式。 这是咱们举的一个例子，在这些里面，在咱们移植工具里面，都会去经过咱们软件移植的这样一些能力去提供给开发者直接使用。

这个是咱们几个工具组建的发布的策略，咱们目前为止是停留在中间这一列上，咱们完成了多OS的适配，好比说咱们支持3~四、7四、7.五、7.六、7.七、7.8对吧？咱们也支持中标麒麟等，咱们也支持了像苏C这样一些的操做系统，就是咱们尽量的去帮尽量覆盖咱们经常使用的这样一些操做系统的类型，咱们也支持了GCC的多个版本，咱们从4.8.9一直支持到目前为止至少8.3，咱们后续会支持到9点几的版本，一直往上支持上去，帮助客户去尽量的简化一些重复劳动，咱们也支持MAC构建工具，也要支持CVK构建工具，将来还会支持automake这样的一个构建工具的一些检查。

支持C，C++的与代码移植，也支持汇编代码的识别，由于刚才前面说了，从汇编指令的角度来说，从你Intrisic的数量来说，这个量很是的大，并且也颇有技术挑战的，就是汇编语言的替换，因此这块咱们会逐步完善。对于加速这一块，咱们是提供一些Intrisic的一些替换，好比说咱们有abs或者有SSE。

咱们也去优化了，像一些经常使用的加速的三方的组件，好比说像一些z-lib的加速或者stapi的一些加速，还有一些scan这种字符扫描的加速的，咱们用鲲鹏的指令去进行优化，进行性能提高，取得了比较可观的一个性能改变都是50%，一倍，甚至更多的3，4倍的这样一个性能提高，因此加速的效果仍是挺明显的。这样也能让用户的软件应用跑在空间当中跑的更快又快又好。

如何去获取咱们这几个工具，咱们能够经过华为的spot网站去下载，也能够经过华为空方社区去下载相应的软件，这上面提供了一些连接。

对于咱们加速库软件，这里的策略是主要采起开源的这种策略，好比说像JDPC或者一些三方组建的，包括一些压缩算法，压缩引擎的，包括这些软件组件，咱们都是把相应的patch去推进到社区里面去。对于硬件加速引擎，咱们也是直接能够从华为的鲲鹏社区上去下载，而后去安装使用，取用起来仍是比较方便的。

鲲鹏社区之后就是华为重点建设的一个和开发者沟通的互动的地方桥梁。在这个地社区里，咱们就能够下载到数百份的软件移植指导以及相应的软件调优的经验，能够在这里面和其余的开发者作互动，作技术上进一步的探讨。 而后不少新的技术资料、技术文档，包括一些白皮书，一些产品设计方案都会在社区里陆续发布，不一样的开发者都能获得一些不一样的信息。

这里列出来，咱们空开发者社区里面如何去获得两工具这几个工具，目前咱们这些工具都已经上线了，9月30号是第1版本，9月30号之后咱们是每个月逐月发布的这样一个节奏，这个节奏将延续到2020年，就是说咱们不是一个短时间行为，咱们会一直从开发者的需求角度来出发，去把这个工具作的更加应用，更加方便帮助用户完成C，C++加代码的90%的工具化移植。

其实在鲲鹏的开发的平台里面，由于鲲鹏是空中平台，是一个新生事物，对吧？对于x86而言是一个新生事物，在这个里面咱们也能感觉到，随着鲲鹏计算平台的壮大，应用愈来愈多，须要大量的开发者去投入到平台的生态建设里面来。因此华为在这里推出了这种线上认证培训的这么一系列的技能提高的活动，包括在线课程，包括云端的实验室，包括线上认证和线下培训，但愿你们可以积极参与，来共同构建华为鲲鹏的生态软件生态。

这里提到一个华为鲲鹏认证开发工程师这么一件事情，就是HCIA认证认证其实在华为内部还在对华为来说仍是蛮有价值的，对开发者来说也是颇有价值的。由于你经过了认证以后，在必定程度上将会成为你进入华为从事软件开发的一个直通车。

因此你们能够关注一下相关的一些培训认证的信息，去找到一个适合本身的方向，而后去在一个更大的舞台上，咱们一块儿来构建华为鲲鹏的软件生态环境，让华为鲲鹏作得愈来愈好。

点击关注，第一时间了解华为云新鲜技术~