模数索引对性能有很大影响

Question

我有一个简单的代码，它对数组中的元素求和并返回它们：

// Called with jump == 0
int performance(int jump, int *array, int size) {
  int currentIndex = 0;
  int total = 0;
  // For i in 1...500_000_000
  for (int i = 0; i < 500000000; i++) {
    currentIndex = (currentIndex + jump) % size;
    total += array[currentIndex];
  }
  return total;
}

我注意到一个奇怪的行为：% size 的存在对性能有非常大的影响（约慢 10 倍），即使 jump 是 0，所以它不断地访问相同的数组元素 (0)。只需删除 % size 就能大大提高性能。

我原以为这只是产生这种差异的模计算，但现在说我用 total += array[currentIndex] % size; 替换我的 sum 行（因此也计算模）性能差异几乎不明显。

我在 arm64 机器上使用 -O3 和 clang 编译它。

这可能是什么原因造成的？

Answer 1

sdiv+msub 延迟听起来很正常，大约是 add 延迟的 10 倍。

即使这个内联的编译时间常数 size 不是 2 的幂，它仍然是一个 multiplicative inverse 和一个 msub（乘减）来获得余数，所以一个 dep至少有两个乘法和一个移位的链。

对于具有恒定大小（即使是正数）的有符号余数的关键路径上可能有额外的几条指令，因为数组也是有符号的int。例如-4 % 3 必须在 C 中生成 -1。

见

• How many CPU cycles are needed for each assembly instruction?
• What considerations go into predicting latency for operations on modern superscalar processors and how can I calculate them by hand?

假设我用 total += array[currentIndex] % size; 替换我的 sum 行（因此也计算模数）

剩余部分不是循环携带的依赖链的一部分。 (https://fgiesen.wordpress.com/2018/03/05/a-whirlwind-introduction-to-dataflow-graphs/)

多个余数计算可以并行进行，因为下一个array[idx] 加载地址仅取决于+= jump 加法指令。

如果您在吞吐量限制上没有瓶颈，那么这些剩余结果可能会以 1/时钟吞吐量准备就绪，并且 OoO exec 在迭代之间重叠 dep 链。唯一的延迟瓶颈是循环计数器/索引和total += ...，它们都是整数add，具有1个周期延迟。

所以说真的，瓶颈很可能是吞吐量（整个循环体），而不是那些延迟瓶颈，除非您在一个非常宽的 CPU 上进行测试，每个循环都可以完成很多工作。 （很惊讶你并没有因为引入% 而变得更慢。除非total 在你不使用结果的情况下在内联后得到优化。）