一、云原生算力再进化

在这里，大家可能会问整体的ECS应用的场景非常广泛，为什么今天会专门选择大数据和视频转码场景来讲，这里有几点原因，第一点，从场景特点来看,大数据和视频转码是比较典型的算力密集型场景。它的整体的在线的业务负载基本上都在80%，甚至超过90%，它与传统的数据库web service负载相比，可能维持在20%，30%，还可能到40%，这是比较高的了，它还有可能通过弹性深度的能力，把负载给降低。

所以说越高的负载，对于传统算力的挑战也就越大，因为毕竟随着负载的增高，它对整体的功耗，包括性能的稳定性，也提出了更高的要求。同时刚才也讲到了，影片实例上线也接近有两年的时间了，这两年的时间在大数据和转码场景也服务了很多的头部客户。同时也助力这些客户取得了非常好的业务收益。所以今天会重点讲，倚天然实力是怎么能够在这些场景中取得非常优异的产品力。

大家可以看一下，在传统的ECS产品设计时，可能更多还是说今天进行传统的英特尔或AMD或者一些其他CPU的迭代。其实在倚天ECS的产品设计之初，我们改变了传统的设计理念。

为什么这么说，整个产品在承接业务过程中将算力分为了两个维度，第一是CPU算力，第二是IO算力。从CPU角度来看，他去承接IOM型的任务，还是有一些瓶颈的。所以我们会把这些IO类的密集型的业务，把它offlow到CIPU的加速卡。相当于以CIPU形态的视角去设计这款产品，如此我们的影片的CPU就可以更专注于算力任务。在这里还有一点是基于物理核的CPU，同时，没有任何的超线程和瑞平的设计理念，它可以更好的承接算力运行的业务场景。结合CIPU实现了网络存储IO能力的加速。如此针对大数据的数据密集型业务，可以提升它的端到端的性能。

在大数据和转码类似的业务场景在，它在云计算整个发展之初，其实已经是传统的应用了，因此倚天710CPU在设计之初，就已经在微架构层面做了特定层面的优化。在ECS产品发布之后，结合软件层面，针对性的在这两个场景里面取得更高的性能和更好的成本收益。因为倚天是比较典型的ARM架构的产品，所以大家可能也会比较担心，它从生态维度会不会有一些不同的地方，倚天在整个开源的数百款的开源软件里，都支持倚天的产品的，而且没有任何的生态上的差异，同时阿里云主流的Part产品，像数据库，容器以及ECI，包括大数据的Part产品，都已经支持了倚天的ECS产品。所以想使用倚天的ECS的同时，想无缝的去使用Part产品的话，可以直接在阿里云官网去关注类似的Part产品组件。同时在近两年的产品的成长过程当中，我们也支撑了数千个客户去使用Part产品，帮助他们进行了相应的降本增效。同时我们纯商业化的规模，也已经突破了数百万盒。

所以这也从侧面证明了我们在整个产品的推演过程当中，也服务了很多的客户。这里重点讲倚天的产品和传统的X86产品的核心差异在哪，大家都知道我们在云上卖ECS规格时，可能有相应的虚拟规格是八核32g，但八核32g在云的角度，其实我们对应的是八个VCPU。

那8个VCPU对于对应的X86实例，今天我们举的是八代的g8y为例，它是对应的八个线程，但对应到我们的倚天实例，其实它是八个物理核。这里面大家可以看线程，就是HT维度它关联的L1、L2cash的大小和今天物理核维度关联的L1、L2cash大小，其实还是有还是有比较大的差异的。因此，物理核针对VCPU对应的物理核算力对比，我们的线程有一个天然算力的优势。

同时还有一点是倚天的产品，再对应到其他的ECS的规格上，还是有一些定位上的差异，这里可以通过右边图可以观看，右边是转码的场景，横轴就是我们的转码的路数，纵轴就是针对我们每一路贡献的FPS值，所以大家可以看纯蓝色的是倚天的ECS产品，然后浅色的是X86的产品。所以说在于转码路数低时，倚天的CPU负载就会非常的低，但CPU负载低时，大家可以看X86的ECS的性能是明显高于以前产品的，所以这也从侧面证明了在一些轻负载的业务场景里其实用倚天产品可能没有办法拿到很好的性能收益，这里不包括成本收益，我只是说性能收益，但如果说我们的转码路数增高之后，随着CPU负载增加时可以看到X86有很明显的性能下降的过程，但是倚天整体的性能的输出和新鲜度还是比较平稳的。这就侧面证明随着CPU负载的变高，尤其是像转码对于计算逆行的场景，倚天能够体现出很好的性能的收益。

第二点是针对CIPU，我们可以看就除了在CPU算力角度的特点，其次就是CIPU针对IO能力。这里面的IO包括网络IO、存储IO。

网络IO支持了EAdma的特性；存储IO支持NVME的特性。这两个特性都能够极大降低整个IO时延，所以说在整个端到端的场景里，也可以进一步的提升我们的性能，同时在整个产品的设计理念角度，以CIPU为中心，采用了双单路的架构，因为倚天CPU采用了五纳米的工艺，它单颗CPU的核数是128物理核。两个CPU是256物理核，其实整体它的爆炸半径还是比较高的，但通过CPU采用12的双单路的设计，既保证了整机的密度，降低了单VCPU的成本，同时也提升了产品的稳定性。

还有一点是除了倚天ECS在整个底座，包括CPU以及CIPU底座物理能力上性能的加持。同时在操作系统，我们会给用户推荐，我们采用的是2013，就是我们自研的操作系统，同时，我们才会采用自研的像装JDK的编译器，以及自研C++的一些ACC编译器。通过操作系统，然后技术软件再包括应用层面的一些垂直的一些优化，通过软硬结合，使得我们把整体的物理核的算力的优势压榨出来，能够去极大的提升整个端到端场景的性能。

所以这里我也重点看了，列举了大数据和视频转码整体上今年的平均的算力提升基本上都在15%以上。下面就会重点看一针对数据场景的最佳实践，大家可以因为现在其实在云上的大数据场景里面，我们普遍采用的是存算分离的架构。存算分离中有很典型的特点，就是说我们对于整个数据传输的效率提出了很高的要求，所以针对此倚天ECS支持200G的网络宽带，同时在整个OSS的传输层面，支持了分布式缓存加速。如此可以极大提效整体的传输数据传输的能力。

其次，在刚才也讲到在大数据场景下，对于CPU负载还是非常高的，但是因此，我们在传统的就是我们原生的物理核的基础之上，同时，我们也会针对性的提出基于倚天优化版的那些文件，如此在整个引擎层面去优化大数据组件，可以再进一步的去提升我们的整个的性能。同时，大数据场景除了对算力维度的要求，因为它数据量比较大，因此它对于整个数据存储的成本，也是比较敏感的，因此在基于倚天的产品解决方案维度，我们支持了弹性临时盘。弹性临时盘对标经常提到的像EBS的三副本产品，它的成本能够节约20%，它的性能也会有一定程度的提升。因此，我们还提出了针对倚天优化版的CSDT的压缩的特性，可以极大的去降低我们的数据存储量，可以去降低我们的存储成本。

结合这些收益，在大数据的典型的组件里面包括像spark，包括have，包括flink，包括ES整体上它的性能提升，都超过了20%以上。列举了目前在倚天应用比较多的比较典型的互联网客户，他原来的整体的业务，是在IDC。然后将他的业务使用倚天产品之后，在我们的整体的算力资源少一半的前提下，它的整体的性能还能提升27%到34%。所以说，它不光集约整体的算力资源，同时还针对整个业务的效能也有比较明显的提升。下面看一段视频场景，其实我们今年主要围绕着两个维度说我们怎么能够降低它的成本，视频成本其实大家可以想一下，它主要就是成本的最大的组成部分是网络的传输。

因为在整个视频转码场景当中，它的算力成本对比网络的传输的成本其实还是大概是2:8的关系，因此，我们怎么能够在保证它的画质的前提下去降低它的码率，同时去提升它的压缩率，如此我们可以去减小它的整体的数据传送量。然后去提效整体在转码场景的性能，同时，我们在相同的算力的算力规格的输出下，去提升它的转码路数。如此，不光是从刚才讲到的网络成本。在算力成本，也能够得到进一步的节约。因此，结合整体的倚天微架构，包括刚才讲到的操作系统层面的系统层面的优化。在转码场景整体的性价比收益是最明显的，超过了80%，像我们的在线教育客户采用倚天的产品，在结合我们优化的方案之后，它整体的性价比收益，就超过了20%。

这里面还有点就在于它更多的还是关注的是转码路数的优化，就是说对标它之前的友商的相同规格的算力，它的转码路数的提升也是非常明显的。还有一点就是大家可能比较关注的大家现在不管是线下的IDC的算力资源，还是存量的一些资源，更多采用的还是X86的架构。

所以说把它的相应的业务迁移到倚天上，可能会有架构层面的担心，就是我的业务能不能无缝的去解决，其实也不用过多担心，因为近两年已经支撑了数千个客户成功的使用我们的倚天产品。同时我们也积累了很多的经验和工具，这里面主要重点提两个工具，就是倚天的迁移工具，第二个就是清纯的调用工具。倚天的迁移工具，就是可以辅助客户把它原有业务的一些代码包放到EZ引擎工具上来，然后会扫出来相应的报告结合报告，客户这边可以进行相应的乱七八糟升级，或者进行相应的重编译，可以极大的提效整体的业务的迁移效率。其次，针对业务迁移上来之后，我们也可以通过清存的一些能力去验证我们的性能是否符合预期，是否符合我们在整个迁移之前的POC性能预期，针对倚天产品，不光是在视频编解码和大数据取得比较好的业务效果。其实在针对所有的这些算力运营场景，尤其是CPU负载超过70%甚至80的这些场景里面，我们都能够取得非常性好的收益。

原因就在于我们是怎么能够把倚天CPU的原生的算力充分的压榨出来，所以这这一点我也列了相应的HPC，包括游戏的一些场景，这里也取得了很多的一些客户，同时针对这些客户的上云后的这些业务效果也是比较明显的。

还有一点是因为倚天整体架构的差异性，刚才讲的就在于现在也发布了倚天社区，因为我相信整个倚天生态的发展离不开开发者，离不开客户。我们可以在倚天社区里面，共同去活跃我们的倚天生态，针对我们在整体的一些业务。

迁移业务性能调优，包括整个业务使用过程当中遇到的任何问题，我们都可以在社区里面找到相应的答案。如果没有相应的答案，我们也可以去进行相应的提问，同时，进入我们的交流群去获取更新的一些基础知识。然后下面会因为我这趴主要是讲一下针对倚天产品维度，包括针对产品维度如何助力我们在大数据转码场景的收益，后面会由我的同事张先国来讲解。针对倚天ES产品，它背后的一些技术特性，可能会更深入的一些技术知识的一些讲解。

 

二、技术Deepdive

本次分享的主题是底层技术跟X86有哪些不同，AI和视频场景下的一些落地，大数据场景下的优势，对落地部署的总结和对未来眼前的展望。

第一部分是面临的四个挑战，比如算力密度，内存强，数据中心的公共开销，还有高能耗的挑战等。为此我们展开了技术方案，首先是视频领域，它是有一些密集的矩阵算法，包括蝴蝶算法，哈特曼的算法，它都是矩阵的加乘矩阵的减算法。我们的加速的方案就是采用SVE来实现，SVE加上的英特尔八核BF16实现倚天的视频场景和AI场景的加速。如此可以批量的计算多个数据同时做矩阵的成和矢量。

第二个是内存强，大家都知道访问内存是比较慢的，业界采用计算的指令是非常快的。业界采用的加速方案就是采用更大的开始，以前开始可以实现十倍以上的吞吐，以更小于十倍的时延倚天采用了对比X86有四倍到两倍之间的开始的容量提升。这是左边的硬件方案，右边是我们测试的方案，倚天可以实现在flink场景下可以开始比降低五倍左右，可以实现flink端到端的性能提升一倍，这就是在开始加速的方案，这是内存强的挑战应对。

第三个是在CPU部署时通常有安全水位，业界一般都是50%，50%的安全水位如果再高超过数字的话，业务的性能时间会抖动，性能很难在线性增加。倚天是独立的物理核，而且是定频的架构，它不会降频，也没有瑞平的问问题，所以它的水位可以提高到70%以上。同时我们也有一些经验在CPU利用率上统计两个HT它是有叠加关系。如果HT到了30%SCR到了40%实际上物理核可能是70%的负载。所以两个叠加到50%各自到50%时很难再向上提升，这也是X86的特点。倚天可能就没有问题，实际统计在低负载下可能有10%的偏离，在重载下可能有20%到30%的偏离，所以倚天就不需要做纠正的问题，它的水位更线性，时间更可控。以上三个方案都是我们硬件上的特点，跟差不多的区别。

软件上结合硬件的特点，软件做了很多优化，比如说从虚拟化层面，从操作系统层面，编译器层面，应用层面来做了一些优化，那从虚拟化和操作系统是开箱即用的，编译器层面是有些加速库可以直接来加速的。我们大概有70来项技术都融合到底层的平台中，然后可以实现10%到30%的性能提升。这是软件结合刚才那几个硬件提加速的方案。刚才讲了底层的几个技术挑战应对方案，现在讲解在落地场景下面有哪些性能收益。

首先讲一下视频场景，即更大的场景C++场景，C场景右边是性能表。在倚天的性能中物理核的算力比较好，经过硬件的调优之后，可以实现以前的spackint比X86高，比g7高50%甚至比GBA还高，接近20%。所以以前的物理核的性能是比较好的。左边是常用的一些应用，比如说算力密集型的，比如视频A，还有IO密集型的，比如说数据库nginxRadius，这些场景的加速方案都是采用比如操作系统的优化和配置的优化，PGU的优化，以及列波加速库的优化实现软件加速。后面是软件加速的效果，视频场景。我们可以实现30%的视频加速。右边表是以X86为基准，以前的开源版本还比高20%左右。那以前还有标准的优软件优化版本，可以高到30%接近40%。

以前还有算法优化的版本，也是可以从我们官网上下载到可以高70%左右，另外我们还有商业化的一些软件来配套，这是倚天的性能，左边表是和X86的对比，大概是高30%到40%的收益。之所以刚才说我们以前在视频场景有很多落地，就是因为我们底层的性能软件加硬件性能比较好。那视频的话有很多场景，左边是视频的点播直播，还有音频，还有解码。那右边两个图是X8264的点播和265的直播，265直播又分了很多细节场景。性能收益大概都是30%左右。性能收益得益于硬件的话，主要是物理核定频。另外它有SVE和int8的加速。另外，还有倚天加速的列布库，我们在很多客户那也做了落地，这是视频场景的收益。刚才讲完视频，下一步就是大数据场景，大家可以看我们的大数据有哪些收益。

在讲大数据之前，它更大的应用是Java应用。加入应用的分为在线和离线，在线就是spring框架double消息服务卡不卡，rocketmq这些业务。离线就是spark、flink、elsearch、presto这些场景。右边是我们先看一下基准性能跟C++一样。基准性能是用dragonware高性能版本，是可以实现比X56高20%,比AMD的版本是高10%的性能,这是Java的性能。

我们在新开普加风通道前行位置，小鹏汽车都做了大规模的应用。另外场地还讲了小鹏的VP，分享在Java上的应用。这是Java的综合性能，后面讲一下大数据的优化方案。大数据场景有很多优化方案，这块不再展开，主要是操作系统编译器应用层的一些小组件，比如说JDK压缩，当然还有一些常见的配置加速。这加速能提供5%到10%的性能，叠加起来可能是20%到40%的收益，这是大数据的软件优化。在大数据的综合场景下，就是18个场景测试，TPC/DS是客户实际的案例，对比AMD有18%的性能收益，它的收益得益于主要物理核大容量，还有ZSTT加速的一些能力，还有dragon，以及阿里巴巴，Linux的操作系统的加速。

右边是压缩场景，它的压缩性能是比较好的，因为大数据的数据要做密集的压缩。这是我们今年华南的互联网客户，他用了几十万核的倚天来做大数据的处理它主要是采用三个加速技术，第一点是计算加速，计算加速就是倚天的ECS，采用刚才说的操作系统JDK做加速。第二点是safer，safer采用弹性缓存盘来实现倚天的更高速度的IO吞吐，同时还能降低成本。第三点是OS的加速，除大带宽的能力之外，还有一些尖端SDK等软件技术来配套，来实现三个方面的加速。

综合的性能收益是达到了两倍，比它原来IDC的服务器是高两倍的端到端吞吐综合成本大幅度下降。刚才讲了spark典型场景这里面是sparknativeengine的场景，netengine主要是采用C++来替代Java的实现，实现它关键的算子来提供优化。以前基于开源的spark，假如是百分之百的性能的话，采用netengine也就是vlogs加gluten能实现性能翻倍，那以前的加速版，还能额外再增加20%到40的性能提升，这是倚天的加速工作，我们的客户又如何使用，我们也可以提供出来。另外我们还有个案例，这是我们PaaS的案例，我们的大数据已经上了EMR，flink。

这里面是今年上线的就叫electsearch，云上的印刷设置可以开箱即用，它也基于倚天版本，也已经推出了性能更好，时间更低的版本。左边是它的应用架构，右边是它测试的水位。在重载的情况下，它可以实现20%的负载降低。同时，成本也能也能降低。是以大search云产品典型的场景。下面是做日志的检索，所以这些业务落地。

讲完这几个场景再看如何落地，以及如何使用倚天。我们提供了三个方案，从简单到难，最简单的方法就是用我们云上的PaaS有两层，数据库层，比如RadiusPoloAdb这些产品已经有了倚天版的数据库。我们可以直接创建时选择倚天板就可以了，成本更低，性能也比较好。另外版本就是我们的大数据，大数据层面的一些PaaS，比如说AmrFlinkNiceComputer，SearchPaaS平台也是可以实现开箱机用的，一共达到了30款产品。上面是支撑了我们的应用，我们客户有数千个客户都已经使用了倚天的平台。

包括内部的淘宝，天猫，支付宝也在使用，钉钉也在使用倚天版的Iaas和PaaS。刚才是第一点方案是PaaS产品开箱即用，第二个就是Iaas产品，如果用以前的ECS部署应用怎么办，那有个简单方案就是booster，也叫应用加速。在创建实例时选择倚天GBY，然后，勾选ALinux操作系统，然后再选择多个应用的加速。勾选完之后，系统会自动帮你安装所有的ARM版的软件，并且把用性能也做好了，加速性能加速的幅度大概是10%到20左右。

部署也比较简单。那另外就是更专业一点的用法，就是客户有自己的软件站以及自己的软件版本。该如何部署，提供了简单的更专业的方案。右边这两个方案，首先是从控制台或者API来创建以前的ECS，可以选择阿里Linux3ARM版的操作系统。也可以自己编译OS，容器层面可以选择直接用ACR就云上的倚天版的容器镜，也可以选择自己去构建ARM的平台。操作系统推荐用自带操作系统的编译器，也可以自己升级辨析，比如说JDK包括C语言的GCC。另外，OS上的应用可以使用，要么最好直接安装云上，我们构建好了几千个常见的应用都已经构建好了二版本，也可以自己去编译，编译之前也可以用倚天来扫描。这是我们的构建方案，即迁移适配的典型路径。

接下来介绍一下未来演进，我们过去从腰侧到商用，做到规模化。已经走过了两年的产品的路程，从芯片到产品应该三年了。最近也实现了很大规模的应用，包括数千个客户，数百万核的落地。我们来年也会出席发布下一代的产品，我也敬请大家期待更强劲的下一代的CPU和下一代的产品实力。这是我们迁移的社区和软件技术站。

 

三、龙蜥解锁倚天底层算力

本次分享的主题是做编译器以及操作系统相关在倚天方面的算力。

这几年一直在做编译器以及操作系统相关的事情。因为编译器和操作系统肯定是和芯片结合最紧密的软件。所以这几天实际上在倚天方面做的事情也比较多。

我的话题有几个关键字，即ARM服务器。在底层是底层软件。具体就是操作系统和编译器这两个层面上的东西。

云栖实际是阿里云开源的操作系统的开源社区。接下来深入的介绍一下编译器以及操作系统这两个方面上的优化。这张图是我们的性能收益，也可以认为是我们从做编译器和操作系统在一件上面做优化的如此动力，因为我们确实发现，从编译器从和操作系统这两个方面上还是能炸出不少性能的，比如说电商这一方面的，就是说我们知道现在大家双11剁手时的流量已经在走以前的服务器了，我们这一年通过在这两个基础软件方面上的提升可以直接在不同的应用上提升10%到20的性能。指的是CPU使用率的下降可以直接对应我们资源的降低，或者说成本的降低，其他的两个场景，比如说像大数据如此我们也获得了10%到20%，如此性能提升数据库的话，多种场景再叠加起来效果更好，可能总和有40%。最高有40%如此性能的提升。

其中前面提到的数据图RDS我们的内部也在使用。优化架构图其实就说明了在做编译器和操作系统的另外问题，即另外的想法，一方面是最底层的云服务器，中间一层是操作系统和编译器，最上层的是各种各样的丰富的应用软件，我们做这层实际上另外动机就是说我们可以对上层的应用实现完全没有侵入的改动，如此也就也可以去获得性能收益，因为实际上无论是变异器还是操作系统，实际上和上层它是解耦的，可以在迁移时完全可以不使用。对自己的应用做任何的改动，也就可以获得更高的性价比，所以说这是我们做这方面的第二个code，实际上是在龙蜥社区架构下去做的，为什么要用社区的形式，实际上我们是出于更多的交流方面的考虑。因为我们知道，其实以前ARM虽然是阿里巴巴的品牌，但是实际上我觉得所有做ARM服务器的人都是志同道合的战友，我们需要如此平台，然后去不停的交流去共同的演进。

所以说我们一想借助龙蜥社区平台，然后去大家一起的去前进龙蜥社区，虽然前面说是阿里创建的，但是实际上的话，我们有46家是理事单位，是共同助力的，然后坚持了这么长时间，我们也够出了一些行业的影响力。比如说我们会有一些重点的客户，像统信和重心，他们会基于开源的操作系统去发布他们自己的衍生版本。另外我们有一些国际项目的合作，像比如说我们这人们团队是。

目前OPENJDK社区Java技术委员会的成员，我们是有对Java世界的任何重要事情的演进具有投票权的，应该是中国唯一的团队。

我们前面提到的是同一社区，是操作系统，相关团队，推出的操作系统就是阿里巴巴clouds，因为现在已经第3代了，我们一般简称为A03，实际上它是对倚天高度适配的操作系统。

并且我们经过了阿里内部大规模如此的检验，然后形成了全线优化的效果。有比相对于centoss，我们向右边的图是有比较明显的性能提升的。另外的话，因为现在centoss7实际上是已经停服了，可能也有很多因为停泊的原因，想追求更长时间的安全保障的话，也会考虑我们A03。前面提到的C++的编译器，我们的阿里的C++编译就是Alibabacloudcompiler简称ACC，实际上是基于LLVM做的变形器我们实际上对无论是构建速度还是运行的效率，都有比较明显的提升。

JDK方面我们是开源了阿里巴巴中国。阿里巴巴专用实际上是我们知道阿里是世界上最大的Java集群之一。那么阿里内部的所有Java应用使用的实际上都是我们阿里巴巴中国标，我们的初衷实际上是在我们通过内部的场景把JDK效果打磨好，然后就是开源能够更好的服务云上的客户。我们优势一方面是性能，像对于像CGB方面，我们相对于OPENJDK差不多有20%左右的性能，如此性能提升。另外方面的话就是标准的，因为大家知道oracle的JDK收费之后，目前JDK事实标准实际上是tom是组织。

开源的就是发布了JDK的发行版。然后龙蜥社区的团队也是基石成员的Ateam组织，它最重要的点就是标准化，它提供标准的构建以及测试方式是我们的专会用他提供的标准的方式去构建，并且我们的测试资源共享的是要通过的方式保证软件的质量。然后上述描述技术软件，我觉得有重要的点就是各种基础软件的版本选择，从这几年的经验看，碰到的坑是最多的点。因为一般的客户做起来，比如说切换到雨天时，他们比较会愿意做的一件事，就是说把所有的基础软件的版本对齐，那么如此会存在问题，虽然ARM的服务器现在的生态已经相当完善了，但毕竟是比较新的事物。所以说很多时候对ARM的支持比较好的软件需要进行一定的升级。那么如果对应的X86的软件版本比较低，直接把软件平移过来，但可能会有各种各样的问题。具体的说就是我这边列出碰到问题最多的三个方面。

第一个是GCC。其实这虽然4.8时就已经有ARM的支持了，但是当时只支持8.0架构。我们知道倚天实际上是支持特性，那么中间8.1，8.2，8.31直到9.0等等这些高级的指令实际上都是无法使用的，所以说我们推荐用比较高版本的。至少要到10.0版本，如此使用上一些性能会很好。有内部现实的例子，就是阿里的数据库。然后他那边最开始爆出来的性能很差。我们去分析一下，发现就是GCC的问题，因为当时他用的比较版本低版本的GCC，他没有用到一些像LSE锁相关的这么高级特性，所以说没有把特性用起来，所以锁的性能低，导致性能很差，换机以后性能立刻提升了50%，所以说这就是比较明显的性能提升。

第二个是glibc，实际上glibc也比较容易忽略，但是企业很重要，因为虽然2.17时glibc就已经支持了，但是这是ARM，但是所有的关键函数都是C1写的。比如说strmcp，它就是用C1写，而高版本的，比如说2.8以后这些关键的函数都是用汇编优化过的，那么性能可能有四倍左右的差异。我们也遇到过故障，就是说因为glibc当时用的是2.17版本，然后strmcp性能性能太低，造成任务堆积，最终就OOM宕机了引起的故障，这也是升级GDC以后，就消失了的，所以说是算是血泪的教训。

第三个gvm方面的话也是有比较多的情况发生，可能要简单介绍一下gvm或者说OPENJDK社区对ARM支持的情况。现在国内用JDK8的还是比较多的，但是JDK8直到2021年4月份时，才真正的在社区支持ARM架构。或者说是AR的效果。时候JDK8到小版本是292版本，换句话说，版本号低于292的全是特区没有支持的版本，可能就有各种各样的问题。我们曾经就有客户，最开始时他用171级的版本在ARM上使用。考查他的应用程序，结果性能非常非常的差。后来我们发现问题就换成TG之后，性能立刻就变得很好了。其实主要的原因还是它社区用的版本没有数据的支持，所以说性能有比较明显的问题，然后像中国，我们实际上把这些关键的版本都放在A03里，如此实际上使用A03，就不用考虑这些问题，但是如果不用A03，我强烈建议大家再用倚天时检查一下这些汽车软件的版本。如果真的没用好的话，肯定会碰到各种各样的稀奇古怪的问题。

现在是我们的一些具体的优化了，种类很多，我分成几类，就是说大数据类，在线业务类，还有数据库类，有些只在两个场景，有些很多场景都有效，像我挑几个重要点的给大家介绍。其中第一点就是64k大页，这是ARM独有的这么功能，因为我们知道一般的Linux的页的大小是4k的，但是ARM的硬件提供的独特的功能，它可以把页放到64k，那么64k的页实际上就是有共享的列表。它对TLB的效果更好，会有更少的TLB，它也会有更少的缺页的中断。所以说整体上性能会有一定的提升，像spark场景的话，我们跑TPCDS可以看到6%的收益，而且从微架构的数据来看的话。确实是所有的像TLB或者血液中断这些指标都是有明显的变好的。

第二个是内核PGO，这是内核方面的优化。PGO是一项变音技术，就是说编译之后，先跑一遍，然后收集一些数据，有这些动态的收集数据之后把这些数据给编译器，然后编译器就可以在第二次编译时去进行针对性的优化，最终获得更好性能更好的内核。然后我们再发附件性能，内核实际上是比较明显的性能提升，特别是一些像CPU内核态，CPU占的比较高的事情是有比较明显的效果的，比如像数据库这边就是MySQL，我们可以看到差不多就10%到15%的性能提升。第三点是对象头压缩，是做在JDK就是这里优化的，我们知道Java里万物皆对象，每个对象就得有个对象头，对象头就是说有各个。

识别出对象，或者说做CC，说它是某个类等等这方面的一些必要的信息的特性，，就是说把对像头的信息做了一些精简。就是说平均每个对象，我们可以节省四到八个字节，整体每个就减少这么多，总体上就是比较多的这么效果的场景，特别对于内存带宽压力比较大的场景是特别有效的。比如说不定的场景，我们这边测下来差不多有10%到20%左右的性能提升，而且有一些客户已经在他们真实应用场景中测过。使用过后性能也得到提升。此外，像阿里的电商这边也明显看到就是GC有所改善，GC频率是降低了的，而且整体就是说吞吐率，换句话说是吞吐率是有所提升。

最后的技术是cboot，可能相对复杂一点，它是我们操作系统硬件，还有编辑整合起来做的这么优化co-bot，它实际上是C和B两个结合。Cos是ARM的硬件的这么功能，它的作用是可以告诉你一条跳转指令，它从起始地址和目的地址就是从哪儿跳到哪儿。有了信息之后，我们把call给我们这些信息转给boot，boot是二进制优化的工具，它可以针对cos给的信息就知道某个函数中，哪些函数应该放在一起，哪些函数可以做AI等等。用这些东西可以做一些针对性的如此的优化，从而比较明显的提升性能。实际上和前面说的PGO有点像。但是PGO是需要源代码编译的，而bot不需要，它可以直接的在二进制上面进行改动进行优化。而且性能是可以跟PGO叠加的，我们可以看到差不多有6到18如此的在PGO的基础上。

那么在MySQL仍然可以获得6到18的性能提升。前面说了很多具体的优化，我们可以把其结合在一起，就是我们推出的优化镜像，优化镜像实际上是在我们标准的ax3的基础上，我们把PGO内核64k的内核还有装ECSVM打到一起，形成定制优化的ECSVM镜像，情况下如果大家去开镜，云市场选到开机CS时，可以从云市场选到镜像，获得开箱即用的这么性能提升。我们是有一些比如说像网关的应用，像网络密集型的应用，开到时候直接就获得了30%左右的开箱即用的性能提升，所以说是比较推荐大家去尝试。

另外一个是booster限购，接下来简单说一下为什么要使用booster，因为boost很大的作用是对操作系统的参数进行调整，但是调整一般是按葫芦起瓢的操作，即不存在放之四海皆准的参数设置。所以我们的思路是客户在开实力时，需要自己去进行场景的选择，而我们就根据客户的选择，把场景最优的参数配置好。如此就会获得相对比较好的性能提升，而且也不用担心对其他场景造成变化，毕竟场景已经指定了。另外除了参数配置以外，我们也会做，比如安装必要的或者性能最优的依赖包等，如此也可以获得比较好的开箱即用的性能，从而提升性能，在倚天上一般会有10%到30%左右的提升。在实际上我们也有相应的例子，即X4、X2.5有客户用的booster，他勾选了之后，开箱节能性能直接提升到30%左右，这是比较明显的性能提升。