即刻获取 HarmonyOS应用开发者基础/高级认证了解详情 



 写点什么

新基建风口下，计算产业的重要程度不言而喻，算力上的投入不仅直接带来 ICT 行业的增长，还对制造、交通、能源、零售等诸多行业带来创新改变，为了追求经济稳固增长，满足市场多元化算力需求，企业对算力要求越来越高，传统 x86 架构渐渐难以满足企业算力需求。

功耗大、通用寄存器数量少、计算机硬件利用率低、寻址范围小等问题凸显，使得 x86 架构劣势渐显难以跟上算力发展的速度，与此同时，ARM 架构在移动互联网盛行的当下开始焕发出别样的生命力，在 ARM 优势极速凸显后，x86 应用向 ARM 的迁移已成为一种趋势，但计算世界终究是牵一发而动全身，应用迁移过程中出现的众多痛点，使得 ARM 应用迁移陷入被动之地。

基于 ARM 架构来设计的鲲鹏，很早前便看到了未来计算机算力架构的迭代之路，建设了鲲鹏社区和华为云学院，指导和帮助开发者进行应用迁移的工作。

7 月 11 日，华为「18 城鲲鹏创新中心开发者创享日·湖南省鲲鹏生态创新中心专场」圆满落地，本场沙龙是由湖南省鲲鹏生态创新中心与华为技术有限公司联合面向湖南 ICT 行业从业人员开展，旨在培养开发者基于鲲鹏底座开发适配应用软件的高阶能力，激发开发者的创新潜能，为湖南省企业的数字化转型积蓄了力量。

本场沙龙以现有的鲲鹏平台软件迁移成功案例为基础，向与会者介绍 x86->ARM 平台软件迁移思路、难点和应对策略，以及迁移后的性能调优方法讲解，帮助开发者更好更快地上手鲲鹏应用迁移。

SO 库迁移

迁移工作中免不了对自己不熟悉的应用进行迁移，当开发者拿到一个不太熟悉的应用时，如何准备迁移工作？需要遵循哪些流程？碰到这种情况不用慌，本次课程向开发者们传授关键的迁移思路及分析过程。

第一个案例是加速库的迁移：ShengBTE 迁移。当拿到一款不太熟悉的软件，首先查看这个软件大概的功能、作用在哪些方面，通过搜索得知 ShengBTE 是一个专业性较强的应用，它被用于计算晶体的热传导率，整个应用使用 C 语言进行编写，配合一些数学函数库来使用。

有了基本了解后，开发者可按照以下 3 个迁移关键步骤来完成 ShengBTE 迁移分析：

1、获取依赖信息。通过官方文档获取应用的依赖栈信息，源码获取方式、编译安装方法，也可结合第三方网站 Archlinux 来搜寻信息。

通过此方法了解到 ShengBTE 包含三个依赖栈，MPI 一个基于 GCC 的编译器，MKL 经过 intel 优化的一个数学函数库，spglib 一个常用的开源数学计算库。

2、分析依赖兼容情况，找出不兼容的依赖分析移植方法。得知了依赖栈，开发者需要根据依赖栈的开源与否和软件平台的兼容情况，对依赖栈进行选择性替换。

MPI 作为 intel 平台使用的编译器，并不兼容鲲鹏，这里使用 Openmpi 作为编译器替换。spglib 作为开源数学计算库，可在鲲鹏直接安装使用。最后一个 MKL 的依赖栈用 lapack 来作为替换，但实际替换完后，编译过程中发现缺少部分函数无法直接使用，这时需要更换替换案例。

3、移植依赖库，将不兼容的依赖替换成 ARM 下兼容的依赖库。经过对 MKL 替换案例的查询，发现可使用 OpenBLAS 做到完美替换，最终安装 OpenBLAS 然后在编译脚本中做相关修改，替换掉链接库完成整个迁移。

以上三点是应用迁移的 3 个关键步骤，从依赖信息的获取，依赖情况分析替换，再到一些没办法使用的依赖栈是怎样去替换的，这些需要开发者心中有清晰的迁移分析流程，才不至于因不熟悉的软件迁移而手忙脚乱。

在迁移分析完成之后，要对编译脚本进行修改，上图中左面插入的图片是官方提供的 Makefile 脚本，右图是修改后的脚本，整个脚本修改涉及到编译参数、编译器、依赖库三项修改。

在编译参数上，Openmpi 的编译命令同样是 MPIF90 无需进行修改，但是 intel MPI 有自己特殊的编译参数 static_intel，在 Openmpi 上并不兼容，需要对其进行相关屏蔽。修改脚本的最后一步，使用之前找到的 OpenBLAS 来完美替换 MKL 依赖库，整体的编译脚本修改就完成了。

最后回顾下整体迁移思路：

分析软件依赖，通过查阅官方文档或者是查阅第三方的网站。

找到依赖后可通过鲲鹏自带的工具去扫描依赖软件是否兼容。

不兼容则需要考虑软件是否开源，如果能得到源代码进行编译是可以适配鲲鹏平台的。

如果软件不开源则需要进行依赖替换，在功能满足的情况下，实在找不到可替换的依赖，就需要开发者进行相关屏蔽，然后再进行编译安装，这就是应用迁移的整体思路。

Maven 工程迁移

NiFi 软件移植，大数据开发者比较了解 NiFi 是一个开源大数据工作平台，将各个数据处理环节模块化，主要目标是简化大数据开发工作量。

在 NiFi 软件迁移过程中，通过命令进行编译打包时发现红字报错，显示没有找到 Jar 包。首先需要排查网络原因，因为在第一次编译时是从国外网站拉取 Jar 包，存在网络不通的情况，经过排查发现网络正常，此时就把目光聚集在 Jar 包本身。

根据相关配置 Pom.xml 去找到 Jar 包相关配置是否正常，详细配置看右边截图展示，groupID 可以理解成 Jar 包在仓库中的具体路径，kudu-binary 代表 Jar 包的名称，version 表示版本，classifier 是个具体的限制条件，在这里主要是用于区分环境，要求找到 aarch64 这样一个版本。

执行 mvn install 之后，系统会解析 Pom.xml 配置信息，先根据 Scope 去判断需不需要拉取，执行相关的测试用例，经过一系列尝试发现 kudu-binary 这个 Jar 包是无法打包出来的，获取不到相关的源码，但这个过程其实不是一无所获的，从官方文档得到的信息是说 kudu-binary 这个 Jar 包是用于测试用例的执行，影响的范围只是 NiFi 下 kudu 的一个小模块里面的一个功能的调用，这部分功能是可以手动做相关测试和执行的，所以尝试将其屏蔽，然后再将两个相关测试用例屏蔽掉，屏蔽以后再进行编译安装，最后完成整体迁移。

在这里回顾下 Maven 迁移整体思路：

如果 Maven 打包失败，首先应该排除网络原因，然后检查 pom.xml 相关配置，确认能从仓库中能找到相关 Jar 包，找不到需要修正相关配置，找得到就要看看是不是其他问题，如果 Jar 包调用报错了，可以根据鲲鹏开发套件 Dependency Advisor 等去做相关扫描，扫描出哪些依赖是否有问题。

如果是 Jar 包一般来说是含 x86 下的 SO 库，如果是含 C 的依赖，就需要对相关 Jar 包进行处理。处理的方法与依赖栈替换一样，要去获取相关的源码，编译得到相关的依赖 Jar 包，编译完之后，替换到本地仓库之中来完成整体打包。

Python 迁移

Python 的通用的迁移思路，主要围绕 Python 特有的配置文件 setup.py 文件，去查看相关的依赖，关注的它的依赖所存放的一些源或者仓库，如果这些源是国外的，没有办法拉取使用则可更换源再次尝试，源没有问题可直接使用 pip 一键安装。

除此之外，开发者可能会遇到一些 SO 包加载不了的问题，可能是域名访问不通，或者是本地解析有问题，这些基本上都是网络的问题，通过把网络问题排查清楚以后，就可以进行安装编译 Python 移植相对简单。

此次软件移植案例主要分享了三类场景，主要是针对 Maven、pom.xml 文件和 setup.py 三类文件进行修改，这些可以解决大部分的迁移问题，主要思路就是定位不兼容的依赖，不兼容依赖可以通过一些手段安装或者替换。

比方说通过源代码进行安装，拉取它的源代码在鲲鹏平台上进行编译安装。如果没有开源就去寻找替代的方案，通过去查阅相关的资料，找到替换的方案以后寻找相关的文件，将它适配到鲲鹏平台上，通过三种主流的应用迁移案例分享，希望能够帮助开发者在软件迁移过程中能有清晰的迁移分析思路。

硬件性能调优

从冯·诺伊曼架构看性能调优方向，基于硬件方面进行性能调优的有四个方向：CPU/内存、磁盘、网卡、应用，以编译器为例，如何优化才能打破 CPU/ 内存瓶颈？这里展开讲解一下编译器的性能优化：

指令布局优化：拆分函数代码，按照冷热指令重新排布，提升指令 Cache 命中率。

内存布局优化：按照内存数据访问频度，组合热数据区域，提升数据 Cache 命中率。

循环优化：分析循环迭代间数据访存依赖关系，对无依赖的循环并行到多核执行，无依赖的数据自动矢量化计算，加速程序运行。

针对 SMP 系统下核数的扩展受到内存总线限制的问题：鲲鹏处理器支持 NUMA 架构，能够很好的解决 SMP 技术对 CPU 核数的制约，NUMA 架构将多个核结成一个节点（Node），每一个节点相当于是一个对称多处理机，一块 CPU 的节点之间通过 On-chip Network 通讯，不同的 CPU 之间采用 Hydra Interface 实现高带宽低时延的片间通讯，在 NUMA 架构下，整个内存空间在物理上是分布式的，所有这些内存的集合就是整个系统的全局内存。每个核访问内存的时间取决于内存相对于处理器的位置，访问本地内存（本节点内）会更快一些。

从上图可以看到，不同 NUMA 内的 CPU core 访问同一个位置的内存，性能是不同的。内存访问时延从高到低为：跨 CPU > 跨 NUMA 不跨 CPU > NUMA 内，因此在应用程序运行时要尽可能的避免跨 NUMA 访问内存，此时可以通过 NUMA-Aware 亲和性资源规划，让内存访问最短路径。