优化 Ubuntu 在 amd64 架构上的性能

by Canonical on 6 February 2024

每个人都希望自己使用的 Linux 发行版运行速度快。当然，这一点不言自明：谁会希望自己的发行版运行速度慢呢？

但是，发行版运行速度快又意味着什么呢？例如，Ubuntu 21.10 将软件包的默认压缩算法改为 zstd，这使得软件包下载和解压缩速度变得更快，从而提高了 Ubuntu 上一项重要操作的性能。当然，还有诸多其他方面的性能，但本篇文章将着眼于一些完全不同的东西——Ubuntu 假定可用的处理器功能。

在本篇文章中，笔者将浅谈一下 amd64 架构的发展史，以及我们正在携手 Intel 进行的一些调研，以更好地利用新一代处理器。

背景

到目前为止，Ubuntu 最常用的架构是 amd64，在某些情况下也称为 x86-64。Ubuntu 仍是针对最早的 amd64 CPU, 即 2003 年的 AMD K8 和 2004 年的 Intel 64 位 Prescott 构建而成，使用的是最原始的指令集架构（ISA）。

多年来，Intel 和 AMD 增加了许多的 ISA 扩展，例如：

• SIMD：SSE3、SSE4、AVX、AVX512 等
• 专用的：RDRAND、AES-NI、VNNI
• 更通用的：cmpxchg16b（原子比较和交换）、vfmadd*（浮点数的融合乘加）、movbe（字节顺序转换）

如不使用这些新指令来提高整个发行版的性能，可就错失良机了。诸如 glibc 和 openssl 这样的核心软件包会在运行时进行检测，以便在新的指令可用时使用新指令，但有更多的软件包并不会这样做。

像 amd64 这样的架构与 POWER 架构之间的一个重大区别在于实现的多样性。多年来，POWER 架构已通过多种方式进行了扩展，但是可以合理假定 2018 年的处理器支持 2013 年处理器所支持的全部指令。这对于 amd64 架构而言却并非完全如此。例如，2007 年在 Penryn 微架构中引入了 SSE4.1，但直到 2012 年才发布了不支持 SSE4.1 的设计（例如，Centerton 系列 Atoms）。此外，AMD 和 Intel 都推出了对方最终实现的扩展（以及从未真正被广泛使用并最终消失的扩展，如 3DNow! 和 TSX）。

长期以来，动态加载器（glibc 的一部分）允许发行版在检测到支持新的 CPU 属性时通过搜索额外的目录来利用这些新的 CPU 属性，但是在 2.33 之前的 glibc 的 amd64 版本上，这些额外的目录系基于特定的、定义不明确的功能选择。例如，据笔者所知，自 2014 年以来，大多数 Intel 处理器上对 /lib/x86_64-linux-gnu/haswell 进行了搜索，但在 AMD 处理器上却完全没有。

2020 年，glibc 开发人员，特别是来自 Red Hat 的 Florian Weimer，受够了这种混乱现状，于是在 libc-alpha 邮件列表上提出了一个解决方案：将合理的 CPU 属性集组合到大多数连同支持的“层级”中，并让动态加载器根据这些层级名称来搜索目录。

然后是解决一些意义不大的技术问题，定义了四个层级，每个层级都包括上一层级：“V1”或基线、“v2”、“v3”、“v4”，这些定义被添加到 “psABI” 规范（大致而言，即定义 amd64 Linux 系统二进制代码的文档）：

参考：psABI 第 14 页

如上所述，很难说特定一代的处理器支持某个特定层级，但大体上，2009 年以后的大多数处理器都支持 v2, 2015 年以后的大多数处理器都支持 v3。

V4 较为复杂：Intel 第 11 代处理器支持，但第 12 代和第 13 代处理器不支持，AMD 新推出的 Zen 4 微架构增加了 V4 支持功能。AVX512 的未来会怎样难以知晓，本文将不予赘述。

从 glibc 到工具链

虽然定义的这些层级的初衷是将动态加载器寻找共享库的过程合理化，但它们也为一组假定在发行版所有部分都可用的指令提供了一个实用标签。支持使用“x86-64-v$N”作为 -march 标记值的功能已添加至 11 版中的 GCC 和 12 版的 LLVM 中。

值得注意的是，我们在本文档中只讨论 C 和 C++ 工具链。虽然发行版显然包含了大量且不断增加的其他语言代码（Python、Go、Rust、Java、Ruby 等），但大部分代码都是 C/C++ 语言。对于部分语言生态系统，特别是 Python，许多性能敏感的代码都是用 C/C++ 语言编写的（例如 numpy）。其他静态编译工具链（如 Rust 和 Go）确实支持选择精确的目标 ISA，但在本文中，我们将只讨论 C 和 C++。  

突破基线？

更改 -march 的默认值是 GCC 打包的一项细微改变，并且部分发行版已经进行了此更改——RHEL9 和 SUSE Tumbleweed（自 2022 年 11 月开始）所针对的目标都是 x86-64-v2。

这些改变虽然会产生成本，但也带来了好处：

• 对于硬件太过老旧而无法支持 v2 指令的用户而言，这些操作系统根本无法工作。
• 对于购买了更好硬件的用户而言，这些操作系统可以更好地利用这些硬件。

对于 RHEL 等商业发行版，这或许仍有一定的意义：如果花钱购买 RHEL（或 SLES，亦或者其他）许可证，则可能已经运行了最新的硬件，或者至少更新不到 10 年以内的硬件所产生的额外成本相当微不足道。值得注意的是，SUSE 推出的新款“自适应 linux 平台”产品最初所针对的目标是 v3，后来又降至 v2。

对于 Ubuntu（或 Fedora）等免费发行版，计算有所不同：允许用户通过安装免费的 linux 发行版来延长硬件寿命是开源世界的一个重要积极的方面，而且仍在Ubuntu 中使用 2008 年一代硬件的用户很有可能是最不能够升级的用户。

也就是说，硬件寿命不是永恒的。几年前，维护对 32 位 x86 电脑的全面支持的成本开始超过收益，于是我们停止构建大多数软件包。做出这样深思熟虑的决定需要以数据作为支持。具体包括：

• 使用情况——有多少 Ubuntu 用户使用的硬件只支持 v1 或 v2？
• 性能——将默认值更改为 x86-64-v2 或 x86-64-v3 会带来多少性能改进？

以上两个问题都不容易回答。

亲自尝试

我们在继续自身的性能分析和进一步评估用户需求的同时，已在社区发布了体验版 Ubuntu 23.04 服务器构建器——可使用 -march=x86-64-v3 和 -mtune=icelake-server，供用户试用。我们考虑了在系统范围内使用 v3 的潜在优点和缺点，您的反馈和观感对我们而言非常宝贵。以下是我们对自己提出的一些问题：

• 总体而言，Ubuntu 的 v3 版本是否比基线 v1 版本更快？正如上面所提到的，这可能意味着从定量基准测试到用户角度对速度更宽松、定性的感觉的诸多差别。
• 是否有某些领域的性能因 v3 而显著提高或出现了下降？
• 这些变化是否会带来破坏？

本篇文章将介绍在哪里可以找到该构建器的安装程序，该构建器不仅是使用重新构建的软件包构建而成的，而且默认安装重新构建存档中的软件包。请注意，此构建器仅用于测试。使用此安装程序安装的系统将不会收到任何安全（或任何其他）更新，并且不适合在生产中使用。

基准测试完成后，我们将发布另一篇文章介绍测试内容和测试结果。请持续关注！