为什么需要做软硬件协同？在后摩尔时代，整个算力的提升逐渐放缓，那怎么提升计算机性能？龙蜥社区 Java 语言和虚拟机 SIG 成员、阿里云智能程序语言与编译器技术总监李三红在
2023 龙蜥操作系统大会上分享了如何通过 Alibaba Cloud Linux 做南向和北向的协同，基于阿里云自研芯片倚天做全栈协同设计和优化，解锁阿里云的底层算力。最后，他也做了 C/C++ 编译器套件 Alibaba Cloud Compiler(ACC)以及 Alibaba Dragonwell 解读。以下为本次分享全文：
（图/龙蜥社区 Java 语言和虚拟机 SIG 成员、阿里云智能程序语言与编译器技术总监李三红）
在这个分享里，我们具体讲讲怎么样通过 Alibaba Cloud Linux 做南向和北向的协同，解锁阿里云的底层算力。开始之前，介绍一下 Alibaba Cloud Linux 和龙蜥社区的关系。
整体上看，龙蜥社区分三层：最上层更多的是龙蜥社区和国际开源社区的合作，包括 Linux Foundation，这是整个龙蜥社区的基础，因为龙蜥本身就是操作系统。除了 Linux Foundation 外，也投入与云原生 CNCF 基金会的合作，以及和 Java 领域的两大顶 级基金会 Eclipse 和 Apache 的合作。中游是原生发行版社区，通过产业协同去促进整个产品演进迭代。当我们有了非常好的开源社区，如何支撑下游可持续的商业模式？龙蜥社区根据场景的不同，提供了三个版本类别：第一个是 Anolis OS 商业版，比如统信、麒麟商业版。第二个是企业定制版，而 Alibaba Cloud Linux 就是龙蜥社区定制版。最后一个就是开源社区的免费版本，如
Anolis OS 23、
Anolis OS 8 等等。
介绍软硬件协同之前，我先分享下我们的思考，就是为什么需要做软硬件协同？我们看下整个产业的计算机算力的大趋势，上图参考自两位图灵奖的获得者 David A. Patterson 和 John L. Hennessy 在 2019 年 ACM 的通信杂志上发表的论文《A New Golden Age for Computer Architecture》。论文回溯了整个计算机体系结构的发展周期，基本上是三个阶段：
-
第一个阶段是在 1985 年前的 CISC 指令集，每年性能提升大概 22%。
-
第二个阶段是从 1985 年到 2005 年以前，是计算算力高速发展的阶段，大概每年 52% 性能提升。
-
第三个阶段，2005 年是一个分水岭。基本上整个计算机的算力进入平缓的增长区域，转向了多核，大概每年 23% 的性能提升。
整个算力的提升逐渐放缓，这就是我们说的后摩尔时代，这里有两个观点分享给大家，第一个是关于硬件和软件的接口抽象。提升硬件和软件的抽象层次，可能带来更大的创新机会。举个例子，很早以前程序员写汇编，后面写 C/C++，再到后面写 Java，编程语言抽象级别的提高带来了很大的创新机会。现代化的 Java 高 级语言的出现更好地匹配了 2000 年后整个互联网蓬勃发展的速度。第二个是在后摩尔时代怎么提升计算机性能？这也是论文提的一个非常重要的观点，垂直整合，一定要做 Vertical Integration。如果没有垂直整合只能任由算力，或者计算机摩尔定律逐渐失效，这也是我们今天探讨的主题。
接下来，我们再介绍两个大的挑战。
第一个挑战是 Power 和 ILP Wall 制约的算力增长。2005 年，C++ 的著 名专家 Herb Sutter 在 Dr. Dobb's Journal(DDJ)发表了著 名的文章《The Free Lunch Is Over:A Fundamental Turn Toward Concurrency in Software》。
相信大家都应该知道这件事，上图也是从这篇文章参考来的，第一个事情，大家看绿线下面的第二条线，时间周期从 1970 年到 2005 年的前后，处理器的时钟速率停止增长。大家都知道 Dennard Scaling 缩放定理，随着晶体管密度的增加，每个晶体管的功耗会下降，因此每平方毫米硅的功耗几乎是恒定的。但是 Dennard Scaling 缩放定律 2007 年的时候开始显著失效，到 2012 年基本没什么作用了。Dennard Scaling 效应的终结，意味着我们无法再按比例降低晶体管的功耗，这导致了“Power Wall”。2006 年到现在，看到的数据中心的处理器频率基本限制在 4GHz 左右, 几乎很难看到通过更高处理器频率来提升性能。
第二个事情是关于指令级并行(ILP)，最早从 1986 年到 2002 年前后，指令级并行是计算体系结构非常重要提升性能的技术。现代处理器的多并发、多发射、更深的流水线导致更高 级的 ILP 非常复杂。为了充满 pipeline，需要预测分支，并“投机性”地将代码放入 pipeline 中以便执行。然而，“投机性”的使用既是 ILP 性能的根源，也是其效率低下的根源。随着现实世界越来越复杂的 Workload 的行为，让这种投机预测变得越来越难(ILP Wall)。这张图的最后这条线，2005 年左右，ILP 不再获得更好的收益，这就是 2005 年的时候为什么要转向多核。从下面的芯片、硬件转向对软件系统并发性能诉求，这其实是一种责任转移，计算机软件将不得不或者说被迫处理好基于多核处理器的大规模并发程序的效率问题，这对软件的并发性能提出了极 致的要求。Go 语言在 2009 年诞生， 将并发（Concurrency）作为 Go 语言的一等公民，通过轻量级的“Goroutines”为并发执行提供支持。最近 Java 21 的发布，把 Virtual Thread 用户态线程纳入到 Java 语言体系中推进。
第二个挑战关于内存墙(Memory Wall)。1994 年，弗吉尼亚大学的教授 William Wulf 和他的研究生 Sally McKee 提出：Memory Wall 将成为未来几十年计算机科学领域非常确定性的挑战。Memory Wall 提出的处理器与内存性能的这种差距，在过去几十年中稳步增长。计算机程序有两个部分组成，数据和指令。内存延迟和内存带宽的限制无法很好的让程序的指令和数据更好地接近 CPU，让 CPU 忙起来（CPU 永远在等内存取数据）。这是内存墙带来的挑战。上面这张图是从《Computer Architecture: A Quantitative Approach》第 5 版中借鉴过来的。时间轴从1980 年到 2010 年，下面是内存，上面是 CPU 的性能。Memory Latency, 以 1980 年 64 KB DRAM 为 Baseline，每年大约 7% 的性能提升。而 Processor 性能在1980-1985，每年大约 22% 的性能提升，1985 年-2000 年，每年大约 52% 性能提升。2000 年-2005 年，每年大约 20% 性能提升。2005 年以后到 2010 年，尽管 per-core basis 的性能并无多大变化，但就像我们前面所述，2005 年后开始转向多核，多核让共享的内存资源的争抢更加加剧。怎么样在软件层面解决内存墙的问题也是非常关键的。
我们怎么看待和解决以上挑战？上图中绿色线是传统的计算机体系结构的定义。为了解决上面的挑战，我们应该从更加的扩展视角看待整个计算机体系结构（红色框表示），包含了从芯片到整个系统软件、编程语言、应用层的扩展视角看整个体系结构。
前面介绍了很多挑战，包括算力放缓、Power Wall、ILP Wall、以及 Memory Wall，那么怎么解决以上问题？
第一是需要更好地跨层级协同设计。从芯片到 OS、编译器、应用，这也是我们阿里云持续在做的。
第二是尽可能面向场景的定制优化。不同的应用场景比如大数据的场景和数据库的场景，Workload 的特点不一样，根据不同场景特点做垂直定制优化。当然，这里有个前提是要确保服务用户的界面保持不变。比如各位在运行 MySQL、Spark 的业务，不会因为是运行阿里云上会有什么不同，换句话说我们会确保 MySQL、Spark 的兼容性，与跑在别的环境并不会有什么不同。这是需要遵循的原则，保证用户界面不会被改变。在这种前提下，尽可能面向场景定制化。
具体怎么做的？基本解法就是以 Alibaba Cloud Linux 为纽带的南北向软硬件全栈协同。上图中从下往上看，下面是各种芯片架构，包括 Intel、AMD、Arm(倚天)，往上面是阿里云的 ECS 实例，ECS 实例上运行的是 Alibaba Cloud Linux，再上面是编译器与运行时，再到不同业务负载。对阿里云用户来说，MySQL、Spark、Flink 都不变，是很正常的开源的 Workload 或者是标准的 Workload。在此基础上, 我们引入了优化领域一个通用的假设 - Close World Assumption( CWA)。这些负载都是跑在阿里云的基础设施之上 ，在此情况下，它其实是个封闭世界的假设。在这个假设下，我们可以把一些限制去掉，做全系统，全栈的优化。上图的右边列举了各个层级优化。比如我们内核会对各种加速器进行支持，PGO内核本质上是针对应用特点的反馈优化，在大数据或者数据库场景有更好的性能表现。64K 可以更好地提升面向内存密集型的负载性能，这是从整个系统看，怎么更好地解决 Memory Wall 带来的性能问题。最上面我们在 Base OS 有全方位的系统配置和服务优化。接下来我们再展开介绍自研的 JDK（Alibaba Dragonwell），自研的 C 和 C++ 编译器（ACC） 。
面向 C、C++ 场景有我们有一套自研的编译器套件 Alibaba loud Compiler，简称ACC。ACC 是基于 LLVM 自主研发。我们从两个维度对 ACC 总结。第一个维度，ACC 面向整个阿里云产品，服务云上的客户，一套编译器可以支撑 Intel X64 和 Arm 两种架构。ACC 编译构建速度和传统的 GCC 比大概有 15% 到 40% 的提速。性能优化方面，相比 GCC 大概有 5-15% 的性能提速。第二个维度是面向倚天710的芯片优化，基于倚天平台上独特的 CoreSight 能力，我们构建了 CoreBolt 技术。CoreBolt 可以追踪应用的指令跳转，通过跳转跟踪信息做后期的代码的 layout 优化。CoreBolt 技术在数据库场景已经有大规模应用，大概有 10%~40% 的性能提升。另外一个是面向倚天的 SVE 指令的支持，C++ 很古老，但现在发展也非常快。C++ 20 有非常好的特性，像 Coroutine、Modules，ACC 编译器对这些现代化的 C++ 特性有比较好的支持。
对 C、C++ 的 Workload，Alibaba Could Linux 中通过叠加我们自研的 ACC 编译器, 完成对 C、C++ 全栈的协同优化。很多数据库的 Workload 都是用 C++ 写的。我们再来谈谈 Java。我们通过 Alibaba Could Linux + Alibaba Dragonwell 来做面向 Java 场景的全栈协同优化。Alibaba Dragonwell 是我们自研的 JDK，帮助优化整个阿里云的Java应用。Alibaba Dragonwell 可以基于 Anolis OS 和Alibaba Could Linux构建和发布。目前发布了 8、11、17 三个 Long Term Support(LTS)版本。Dragonwell 分两个版本，一个是标准版，功能基本上和OpenJDK 一样。另一个版本是扩展版，带来很多面向云场景增强，比如 Wisp(协程)，RAS 增强都在扩展版中。上面是不同的平台支持、质量体系、社区维护。我们也在积极参与 Java 领域开源和标准工作，阿里云是 Java 标准委员会 JCP-EC 成员（中国唯 一），也是 GraalVM 项目咨询理事会成员（中国唯 一）。作为 Eclipse Adoptium 工作组战略基石成员，我们也参与 Eclipse Adoptium 社区治理，讨论和建立 JDK 发行版兼容，稳定性标准，拥有 PMC 席位（中国唯 一）。
上图是关于更多 Alibaba Could Linux 的资源链接，如果需要了解更多 Alibaba Could Linux 产品的情况，可以扫码入群或点击链接做更多了解
技术 PPT ：关注龙蜥公众号【OpenAnolis 龙蜥】，回复“龙蜥课件”获取。
—— 完 ——
