JEP 414：向量 API（第二孵化器）

QWen Max 中英对照 JEP 414: Vector API (Second Incubator)

总结

引入一个 API，用于表达矢量计算，该 API 在支持的 CPU 架构上能够可靠地在运行时编译为最佳的矢量指令，从而实现优于等效标量计算的性能。

历史

Vector API 由 JEP 338 提出，并作为孵化 API 集成到 Java 16 中。我们在此提议纳入针对反馈的改进，以及性能提升和其他重要的实现增强。具体包括以下显著变更：

增强 API 以支持对字符的操作，例如用于 UTF-8 字符解码。具体来说，我们添加了在 short 向量和 char 数组之间复制字符的方法，以及用于与整数向量进行无符号比较的新向量比较运算符。
增强 API 以实现 byte 向量与 boolean 数组之间的转换。
使用 Intel 的短向量数学库 (SVML) 在 x64 上为超越函数和三角函数的逐通道操作提供内在支持。
对 Intel x64 和 ARM NEON 实现进行通用性能增强。

目标

清晰简洁的 API —— 该 API 应能够清晰简洁地表达广泛的矢量计算，这些计算由循环内的矢量操作序列组成，并可能包含控制流。应该可以表达出对于矢量大小或每个矢量的通道数通用的计算，从而使这些计算能够在支持不同矢量大小的硬件上移植。
平台无关性 —— 该 API 应与 CPU 架构无关，从而支持在多种架构上实现矢量指令。正如 Java API 中常见的那样，当平台优化和可移植性发生冲突时，偏向于使 API 可移植，即使这会导致某些特定平台的习惯用法无法在可移植代码中表达。
在 x64 和 AArch64 架构上可靠的运行时编译和性能 —— 在具备能力的 x64 架构上，Java 运行时（特别是 HotSpot C2 编译器）应将矢量操作编译为相应的高效且高性能的矢量指令，例如 Streaming SIMD Extensions (SSE) 和 Advanced Vector Extensions (AVX) 所支持的指令。开发人员应确信他们表达的矢量操作会可靠地映射到相关的矢量指令。在具备能力的 ARM AArch64 架构上，C2 同样会将矢量操作编译为 NEON 所支持的矢量指令。
优雅降级 —— 有时矢量计算在运行时不能完全表示为一系列矢量指令，可能是因为架构不支持某些所需指令。在这种情况下，Vector API 实现应优雅降级并仍然能正常工作。如果矢量计算不能有效地编译为矢量指令，这可能涉及发出警告。在没有矢量支持的平台上，优雅降级将生成与手动展开循环竞争的代码，其中展开因子是所选矢量中的通道数。

非目标

增强 HotSpot 中现有的自动向量化算法不是目标。
在 x64 和 AArch64 以外的 CPU 架构上支持向量指令不是目标。然而，重要的是要说明，正如目标中所表达的，API 不应排除此类实现。
支持 C1 编译器不是目标。
支持由 Java strictfp 关键字定义的严格浮点计算不是目标。在浮点标量上执行的浮点运算的结果可能与在浮点标量向量上执行的等效浮点运算不同。但是，这一目标并不排除表达或控制浮点向量计算所需精度或可再现性的选项。

动机

向量计算由一系列对向量的操作组成。向量包含一个（通常）固定数量的标量值序列，这些标量值对应于硬件定义的向量通道数量。对具有相同数量通道的两个向量应用二元操作时，会对每个通道应用等效的标量操作，操作对象为来自每个向量的两个对应的标量值。这通常被称为单指令多数据 (SIMD)。

向量操作表达了一定程度的并行性，这种并行性使得在单个 CPU 周期内可以完成更多工作，从而可能带来显著的性能提升。例如，给定两个向量，每个向量包含八个整数的序列（即八个通道），这两个向量可以通过一条硬件指令相加。向量加法指令可以在通常对两个整数执行一次整数加法所需的时间内，操作十六个整数，完成八次整数加法。

HotSpot 已经支持自动向量化，它可以将标量操作转换为超级字（superword）操作，然后映射到向量指令。可转换的标量操作集合是有限的，并且对代码形状的变化也较为脆弱。此外，可能仅使用了可用向量指令的一个子集，从而限制了生成代码的性能。

如今，一个希望编写能被可靠地转换为超字（superword）操作的标量操作的开发者，需要理解 HotSpot 的自动矢量化算法及其局限性，从而实现可靠且可持续的性能。在某些情况下，可能无法编写出可转换的标量操作。例如，HotSpot 不会将用于计算数组哈希码的简单标量操作转换为矢量操作（因此，Arrays::hashCode 方法不会被转换），也无法自动矢量化用于按字典顺序比较两个数组的代码（因此我们添加了一个用于字典序比较的内在函数）。

Vector API 旨在通过提供一种使用现有的 HotSpot 自动矢量化器编写复杂矢量算法的方法来改善这种情况，但其用户模型使矢量化更加可预测和稳健。手写矢量循环可以表达高性能算法，例如矢量化的 hashCode 或专门的数组比较，而自动矢量化器可能永远无法优化这些算法。许多领域都可以从这种显式的 Vector API 中受益，包括机器学习、线性代数、密码学、金融以及 JDK 本身的代码。

描述

向量由抽象类 Vector<E> 表示。类型变量 E 被实例化为向量所涵盖的标量基本整数或浮点元素类型的装箱类型。向量还有一个 形状（shape），它定义了向量的大小（以位为单位）。向量的形状决定了当 HotSpot C2 编译器编译向量计算时，Vector<E> 的实例如何映射到硬件向量寄存器。向量的长度，即通道数或元素数，是向量大小除以元素大小的结果。

支持的元素类型（E）集合为 Byte、Short、Integer、Long、Float 和 Double，分别对应于标量基本类型 byte、short、int、long、float 和 double。

所支持的形状集对应于 64、128、256 和 512 位的向量大小，以及 max 位。512 位的形状可以将 byte 打包到 64 条车道，或将 int 打包到 16 条车道，这样形状的向量可以一次操作 64 个 byte 或 16 个 int。max 位形状支持当前架构的最大向量大小。这使得支持 ARM SVE 平台成为可能，该平台的实现可以支持从 128 位到 2048 位之间的任何固定大小，以 128 位为增量。

我们相信，这些简单的形状通用性足以在所有相关平台上发挥作用。然而，随着我们在孵化此 API 期间对未来的平台进行试验，我们可能会进一步修改形状参数的设计。这样的工作并不在此项目的早期范围内，但这些可能性部分地影响了形状在 Vector API 中的当前角色。（更多讨论见下文的未来工作部分。）

元素类型和形状的组合决定了向量的种类，由 VectorSpecies<E> 表示。

对矢量的操作分为通道内或跨通道。

一种**按通道（lane-wise）**操作会对一个或多个向量的每个通道并行应用标量运算符，例如加法。按通道操作通常（但并非总是）会生成一个长度和形状相同的向量。按通道操作进一步分为一元、二元、三元、测试或转换操作。
一种**跨通道（cross-lane）**操作会在整个向量范围内应用操作。跨通道操作会产生一个标量或可能形状不同的向量。跨通道操作进一步分为排列或归约操作。

为了减少 API 的表面积，我们为每类操作定义了集合方法。这些方法将运算符常量作为输入；这些常量是 VectorOperator.Operator 类的实例，并在 VectorOperators 类中的静态 final 字段中定义。为了方便起见，我们为一些常见的全服务操作（如加法和乘法）定义了专用方法，可以用来替代通用方法。

向量的某些操作（例如转换和重新解释）本质上是改变形状的；也就是说，它们生成的向量形状与其输入的形状不同。向量计算中的形状改变操作可能会对可移植性和性能产生负面影响。因此，API 在适用的情况下定义了每种形状改变操作的形状不变版本。为了获得最佳性能，开发者应尽可能使用形状不变的操作编写形状不变的代码。在 API 规范中，形状改变的操作会被明确标识出来。

Vector<E> 类声明了一组所有元素类型都支持的常用向量操作方法。对于特定于元素类型的操作，Vector<E> 有六个抽象子类，每个支持的元素类型各一个：ByteVector、ShortVector、IntVector、LongVector、FloatVector 和 DoubleVector。这些特定类型的子类定义了额外的操作，这些操作绑定到元素类型，因为方法签名引用的是元素类型或相关的数组类型。此类操作的示例包括归约（例如，将所有通道求和为标量值）以及将向量的元素复制到数组中。这些子类还定义了针对整数子类型（例如，按位操作如逻辑或）和浮点类型（例如，超越数学函数如指数运算）的其他全服务操作。

作为一个实现细节，这些 Vector<E> 的类型特定子类会进一步由针对不同向量形状的具体子类进行扩展。这些具体子类并不公开，因为没有必要提供针对类型和形状的特定操作。这将 API 的覆盖范围缩减为关注点的总和，而非乘积。具体 Vector 类的实例通过基类 Vector<E> 及其类型特定子类中定义的工厂方法获取。这些工厂方法以所需向量实例的种类作为输入，并生成各种类型的实例，例如元素为默认值的向量实例（即零向量），或从给定数组初始化的向量实例。

为了支持控制流，某些矢量操作可选地接受由公共抽象类 VectorMask<E> 表示的掩码。掩码中的每个元素是一个布尔值，对应于一个矢量通道。掩码选择操作所应用的通道：如果该通道的掩码元素为 true，则应用该操作；如果掩码为 false，则采取某种替代动作。

与向量类似，VectorMask<E> 的实例是为每种元素类型和长度组合定义的非公共具体子类的实例。在操作中使用的 VectorMask<E> 实例应与参与操作的向量实例具有相同的类型和长度。向量比较操作会产生掩码，然后可以将这些掩码用作其他操作的输入，以选择性地对某些通道进行操作，从而模拟流控制。还可以使用 VectorMask<E> 类中的静态工厂方法来创建掩码。

我们预计，掩码在对于形状通用的矢量计算的发展中将发挥重要作用。这一预期基于谓词寄存器（与掩码等效）在 ARM 可扩展矢量扩展（Scalable Vector Extensions）和 Intel 的 AVX-512 中的核心重要性。

示例

下面是一个对数组元素进行简单标量计算的例子：

void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}
java

（我们假定数组参数具有相同的长度。）

下面是一个使用 Vector API 的等效向量计算：

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

void vectorComputation(float[] a, float[] b, float[] c) {
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    for (; i < upperBound; i += SPECIES.length()) {
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i);
    }
    for (; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
    }
}
java

首先，我们从 FloatVector 中获取一个形状最适合当前架构的首选物种（species）。我们将其存储在一个 static final 字段中，这样运行时编译器会将该值视为常量，从而更好地优化向量计算。主循环随后以向量长度（即物种长度）为步幅迭代输入数组。它从数组 a 和 b 的相应索引处加载给定物种的 float 向量，流畅地执行算术运算，然后将结果存储到数组 c 中。如果在最后一次迭代后还剩下任何数组元素，则这些尾部元素的结果将通过普通的标量循环计算。

该实现可在大型数组上达到最佳性能。HotSpot C2 编译器在支持 AVX 的 Intel x64 处理器上生成类似于以下内容的机器代码：

43%  / │  0x0000000113d43890: vmovdqu 0x10(%r8,%rbx,4),%ymm0
38%  │ │  0x0000000113d43897: vmovdqu 0x10(%r10,%rbx,4),%ymm1
70%  │ │  0x0000000113d4389e: vmulps %ymm0,%ymm0,%ymm0
60%  │ │  0x0000000113d438a2: vmulps %ymm1,%ymm1,%ymm1
16%  │ │  0x0000000113d438a6: vaddps %ymm0,%ymm1,%ymm0
86%  │ │  0x0000000113d438aa: vxorps -0x7ad76b2(%rip),%ymm0,%ymm0
66%  │ │  0x0000000113d438b2: vmovdqu %ymm0,0x10(%r9,%rbx,4)
20%  │ │  0x0000000113d438b9: add    $0x8,%ebx
44%  │ │  0x0000000113d438bc: cmp    %r11d,%ebx
         \ │  0x0000000113d438bf: jl     0x0000000113d43890

这是使用 Project Panama 开发仓库的 vectorIntrinsics 分支中的 Vector API 原型和实现，对上述代码进行 JMH 微基准测试的输出结果。这些生成的机器代码的热点区域清楚地展示了向量寄存器和向量指令的转换。为了使转换更加清晰，我们禁用了循环展开；否则，HotSpot 会使用现有的 C2 循环优化来展开此代码。所有的 Java 对象分配均被省略。

运行时编译

Vector API 有两种实现。第一种是用 Java 实现的操作，因此它是可行的，但不是最优的。第二种是为 HotSpot C2 运行时编译器定义了内在的矢量操作，以便在可能的情况下，它可以将矢量计算编译到适当的硬件寄存器和矢量指令。

为避免 C2 内部函数激增，我们定义了与各种操作（如一元、二元、转换等）相对应的广义内部函数，这些函数接受一个描述要执行的具体操作的参数。大约二十个新的内部函数支持整个 API 的内部函数化。

我们期望最终将矢量类声明为原始类，正如 Project Valhalla 在 JEP 401（原始对象）中所提出的那样。在此期间，Vector<E> 及其子类被视为基于值的类，因此应避免对其实例进行依赖标识的操作。尽管矢量实例在抽象上由通道中的元素组成，但这些元素并未被 C2 标量化 —— 矢量的值被视为一个整体单元，就像 int 或 long 一样，映射到适当大小的矢量寄存器。C2 对矢量实例进行了特殊处理，以克服逃逸分析的局限性并避免装箱。

用于超越运算的 Intel SVML 内部函数

Vector API 支持对浮点向量进行超越函数和三角函数的按通道操作。在 x64 架构上，我们利用 Intel 短向量数学库（SVML）为这些操作提供优化的内部实现。这些内部操作的数值属性与 java.lang.Math 中定义的对应标量操作相同。

SVML 操作的汇编源文件位于 jdk.incubator.vector 模块的源代码中，存放在特定操作系统的目录下。JDK 构建过程会将这些源文件针对目标操作系统编译为一个 SVML 专用的共享库。这个库相当大，大小接近 1 MB。如果通过 jlink 构建的 JDK 镜像中省略了 jdk.incubator.vector 模块，那么 SVML 库将不会被复制到该镜像中。

该实现目前仅支持 Linux 和 Windows。由于提供带有必要指令的汇编源文件需要大量工作，我们将会在之后考虑 macOS 的支持。

HotSpot 运行时会尝试加载 SVML 库，如果存在，则将 SVML 库中的操作绑定到命名的存根例程。C2 编译器会生成代码，根据操作和向量种类（即元素类型和形状）调用相应的存根例程。

未来，如果 Project Panama 扩展了对本地调用约定的支持以支持向量值，那么 Vector API 的实现可能能够从外部源加载 SVML 库。如果这种方法没有性能影响，那么就不再需要以源代码形式包含 SVML 并将其构建到 JDK 中。在此之前，鉴于潜在的性能提升，我们认为上述方法是可以接受的。

未来工作

如上所述，我们最终期望将矢量类声明为原始类。此外，我们期望利用 Project Valhalla 的原始类泛型特化功能，使得 Vector<E> 的实例可以是具体类型为原始类型的原始值。这将使优化和表达矢量计算变得更加容易。一旦我们能够在原始类上进行泛型特化，可能不再需要特定类型的 Vector<E> 子类型（例如 IntVector）。我们计划在多个版本中孵化此 API，并在原始类及相关设施可用时对其进行调整。

我们希望在支持硬件屏蔽的架构上提升接受掩码的矢量操作的性能。如果掩码更加高效，则上面的示例可以写得更简单，无需使用标量循环处理尾部元素，同时仍然能够实现最佳性能：

void vectorComputation(float[] a, float[] b, float[] c) {
    for (int i = 0; i < a.length; i += SPECIES.length()) {
        // VectorMask<Float>  m;
        var m = SPECIES.indexInRange(i, a.length);
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i, m);
        var vb = FloatVector.fromArray(SPECIES, b, i, m);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i, m);
    }
}
java

我们计划在 JEP 412（外部函数与内存 API）脱离孵化状态后，增强 API 以使用该功能加载和存储矢量。描述矢量种类的内存布局可能会派上用场，例如用于跨由矢量元素组成的内存段进行步进。
我们预计将改进实现，以优化包含矢量化代码的循环、支持 ARM SVE 平台，并随着时间推移逐步提升性能。

替代方案

HotSpot 的自动向量化是一种替代方法，但需要大量工作。而且，与 Vector API 相比，它仍然很脆弱且有局限性，因为对于复杂控制流进行自动向量化非常难以实现。

总体而言，即使经过数十年的研究（尤其是针对 FORTRAN 和 C 数组循环），除非用户异常仔细地关注编译器准备自动向量化的确切循环的未明文规定的约定，标量代码的自动向量化似乎并不是优化用户随意编写的循环的可靠策略。编写一个无法自动向量化的循环太容易了，其原因可能没有任何人类读者能够察觉。即使在 HotSpot 中，多年来的自动向量化工作只给我们留下了许多仅在特殊场合工作的优化机制。我们希望更频繁地利用这些机制！

测试

我们将开发组合单元测试，以确保覆盖所有操作、所有支持的类型和形状，以及各种数据集。

我们还将开发性能测试，以确保性能目标得到满足，并且矢量计算能够高效映射到矢量指令。这可能包括 JMH 微基准测试，但还需要更多实际有用的算法示例。此类测试最初可能会存放在特定于项目的代码库中。鉴于测试的比例以及它们的生成方式，在集成到主代码库之前，可能需要进行整理。

作为性能测试的备份，我们可以创建白盒测试，以强制 JIT 向我们报告 Vector API 源代码确实触发了向量化。

风险与假设

API 可能会对 x64 架构上支持的 SIMD 功能产生偏向性风险，但通过支持 AArch64 可以减轻这一风险。这主要适用于显式固定的受支持形状集合，这些形状不利于以形状通用的方式编写算法。我们认为 Vector API 的大多数其他操作偏向于可移植算法。为了降低这种风险，我们将考虑其他架构，特别是 ARM Scalar Vector Extension 架构，其编程模型会动态调整以适应硬件支持的单一固定形状。我们欢迎并鼓励在 HotSpot 的 ARM 特定领域工作的 OpenJDK 贡献者参与这项工作。
Vector API 使用包装类型（例如 Integer）作为基本类型（例如 int）的代理。这一决策是由于 Java 泛型当前的限制所致，因为 Java 泛型对基本类型并不友好。当 Project Valhalla 最终引入功能更强大的泛型时，当前的决策可能会显得笨拙，并且可能需要更改。我们假设这些更改可以在不过度破坏向后兼容性的情况下实现。

总结​

历史​

目标​

非目标​

动机​

描述​

示例​

运行时编译​

用于超越运算的 Intel SVML 内部函数​

未来工作​

替代方案​

测试​

风险与假设​

总结

历史

目标

非目标

动机

描述

示例

运行时编译

用于超越运算的 Intel SVML 内部函数

未来工作

替代方案

测试

风险与假设