Helium 技术讲堂 | 克服 Amdahl 定律的影响

本文转载自：Arm社区

串行代码在循环处理中很常见，串行代码造成的开销可能相当大，特别是对于小循环。下面的内存复制代码就是一个很好的例子：

处理器必须记录多项数据：

在处理中断时，跟踪记录所有这些数据可能会造成问题，因此一些 DSP 只需要延迟中断，直到循环完成。如果要执行大量的迭代，这可能需要相当长的时间，而且完全不符合 Cortex-M 处理器应该实现的快速和确定性中断延迟的需求。这种方法也不适用于处理精确故障，如权限违规导致的内存管理故障异常 (MemManage)。另一种方法是增加额外的寄存器来处理循环状态。但这些新寄存器必须在异常进入和返回时保存和恢复，而这又会增加中断延迟。为了解决这个问题，Armv8.1-M 采用了一对循环指令：

在循环末尾添加循环指令有一个很好的副作用， 如果缓存的循环信息刷新，该指令将重新执行。然后，重新执行 LE 指令将重新填充缓存。 如下图所示，由于无需保存循环开始和结束地址，因此现有的快速中断处理功能得以保留。

除了第一次迭代和从中断恢复时的一些设置外，所有时间实际上都花在了内存复制而不是循环处理上。此外， 由于处理器事先知道指令的顺序，因此总能用正确的指令填充流水线。这样就消除了流水线清空和由此导致的分支损失。 因此，我们可以将这一循环矢量化，不必再担心 Amdahl 定律的影响，我们（暂时）克服了这些困难。

在对代码进行矢量化时，一个循环通常以不同类型的指令开始和结束，例如矢量加载 (VLDR) 和矢量乘加 (VMLA)。执行这样的循环时，会产生一长串不间断的交替 VLDR/VMLA 操作（如下图所示）。 这种不间断的链条使处理器能够从指令重叠中获得最大益处，因为它甚至可以从一个循环迭代结束重叠到下一个迭代开始，从而进一步提高性能。 关于指令重叠的更多信息，可参阅： 《Arm Helium 技术诞生的由来：为何不直接采用 Neon？》

当需要处理的数据量不是矢量长度的倍数时，矢量化代码就会出现问题。典型的解决方案是先处理全矢量，然后用一个串行/非矢量化尾部清理循环来处理剩余的元素。不知不觉中，Amdahl 定律又出现了，真是令人不胜其烦！Helium 中的矢量可容纳 16 个 8 位数值，因此在我们对 31 字节的 memcpy 函数进行矢量化时，仅有不到一半的拷贝将由尾部循环连续执行，而不是由矢量指令并行执行。为了解决这个问题，我们增加了循环指令的尾部预测变体（如 WLSTP、LETP）。对于这些尾部预测循环，LR 保存的是要处理的矢量元素的个数，而不是要执行的循环迭代的次数。循环开始指令 (WLSTP) 有一个大小字段（下面 memcpy 函数示例中的“.8”），用于指定要处理的元素的宽度。

如果您曾见过其他优化的 memcpy 例程，可能会对这个例子的简单程度感到惊讶，但对于 Helium 来说，这已经是最好的完全矢量化解决方案所需要的一切了。具体工作原理如下： 处理器使用大小字段和剩余元素的数量来计算剩余迭代次数。如果最后一次迭代要处理的元素个数少于矢量长度，则矢量末尾相应数量的元素将被禁用。因此，在上文复制 31 个字节的例子中，Helium 会在第一次迭代时并行复制 16 个字节，然后在下一次迭代时并行复制 15 个字节。 这不仅可以避免 Amdahl 定律的影响，实现该有的性能，还可以完全消除串行尾码，减少代码量，简化开发过程。

由于面临高性能目标和严格的面积/中断延迟限制，我们在设计 Helium 时就像在设计一个多维拼图，且其中一半的形状是已经固定的。架构中看似毫不相干的部分可以相互作用，产生意想不到的效果或助力解决一些有趣的难题。

整个 Helium 研究团队和我都无比期待看到 Helium 技术能够为全新的应用带来有力的支持。 目前 Cortex-M 已有三款产品支持 Helium 技术——Cortex-M52、Cortex-M55 和 Cortex-M85 ，我迫不及待看到 Helium 技术持续赋能我们生态伙伴的 AI 创新应用。