Eigen NEON 后端是不是经过优化以利用从 ARM A76 开始存在的 2x128b NEON 执行单元？

Posted 2023-02-16

【中文标题】Eigen NEON 后端是不是经过优化以利用从 ARM A76 开始存在的 2x128b NEON 执行单元？

【英文标题】：Is Eigen NEON backend optimized to take advantage of the 2x128b NEON execution units which exist starting from ARM A76?Eigen NEON 后端是否经过优化以利用从 ARM A76 开始存在的 2x128b NEON 执行单元？

【发布时间】：2020-09-02 14:41:13

【问题描述】：

查看 Eigen 文档，不清楚它是否在 A76 CPU 内核发布后进行了更新，以利用它包含的更广泛的 SIMD（2x128b 与之前的 128b） 我希望开发团队中的某个人（或专家用户）可以帮助澄清这一点。

【问题讨论】：

我不知道答案（仅将 Eigen 用于 AMD64），但我想我知道如何找出答案。 AFAIK Eigen 不使用汇编。这意味着它们发出手动矢量化代码的唯一方法是内在函数。在 arm.com 上的 NEON 文档中，找到处理 256 位长向量的乘法或 FMA 内在函数，然后在 Eigen 的文件夹中“在文件中查找”，搜索该内在函数。 NEON 开发人员不使用术语“FMA”，它被称为 MLA，表示乘法+累加。

【参考方案1】：

我对 Eigen 并不特别熟悉，但总的来说，无需对 SIMD 代码做太多操作即可利用不同数量的硬件执行单元 - 特别是当 CPU 支持乱序执行时，它们当有更多的执行单元时，将拾取更多可以并行执行的指令。

如果编译例如带有编译器的 SIMD 内在函数，如果被告知专门针对该内核进行优化（并且如果编译器知道内核的调度特征），编译器可能能够调整代码的确切调度。手写汇编代码也是如此——它可以针对不同内核的特性进行一些调整和调整，但在大多数情况下，它不会发生太大变化；更强大的核心将更快地执行它。

（主要影响代码编写方式的更大图景的因素，这需要适当的重写才能利用，通常是指令集中可用的寄存器数量 - 但这不会随着具有更多执行单元的硬件实现。）

【讨论】：

这通常是正确的，尽管有时您可能需要具有更好计算强度的完全不同的策略才能真正利用更宽的内核。 （例如，通常每次加载和存储只执行 1 个 FMA 的算法只会成为加载/存储执行单元吞吐量的瓶颈，即使有 2 个 FMA 单元，如果没有更多的加载和存储单元。）但是，我d 希望 Eigen 具有比可能的计算强度更高的计算强度，因为如今大多数 x86-64 CPU 具有 2 个 FMA、2 个负载和 1 个存储执行单元。