为何一行代码next += val;会导致性能下降10倍？

这背后的核心原因是那行next += val破坏了CPU指令流水线的并行执行，把内存访问的延迟完全暴露了出来，让循环的执行速度从CPU计算主导变成了内存访问主导。

详细分析 #

我们先对比两个函数的循环依赖关系：

1. rand_read_1的执行流程（快的版本）

在这个函数里，循环内的关键操作是：

my_rand64(&next);  // 仅依赖上一轮的next值
next %= nr_words;
val = ptr[next];   // 依赖next，但不影响下一轮的next生成
sum += val ^ next;

这里的伪随机数生成（my_rand64）只依赖上一轮循环结束时的next值，和内存加载操作（val = ptr[next]）没有任何依赖关系。

因为你的ptr是1GB的大内存，远超过CPU缓存（你的Xeon 4210 L3缓存仅13.75MB），所以随机访问ptr[next]几乎都是缓存未命中，需要从主内存加载，延迟大概在几十纳秒。但CPU可以利用指令流水线，在等待内存返回数据的同时，提前计算下一轮循环的next值——相当于把内存延迟“隐藏”在了计算过程中，所以整体性能接近CPU的计算能力。

2. rand_read_2的执行流程（慢的版本）

多了一行next += val后，循环的依赖链被彻底改变：

my_rand64(&next);
next %= nr_words;
val = ptr[next];
sum += val ^ next;
next += val;  // 新增：next的更新依赖于内存加载的val

现在，下一轮循环的my_rand64(&next)必须等待val从内存加载完成才能执行——因为next的新值直接依赖于val。这直接打断了CPU的流水线并行：CPU在等待内存返回的这段时间里，完全无法进行下一轮的计算工作，只能空等。

原本可以被隐藏的内存延迟，现在变成了每一轮循环必须等待的固定开销，自然导致性能骤降。

额外说明：为什么next += val没有被编译器优化掉？ #

你可能会疑惑：ptr被memset成了全0，val应该是0，那next += val等价于next += 0，编译器为什么不直接删掉这行？

这是因为编译器对堆内存（malloc分配的内存）的优化是保守的：它默认认为堆内存可能被其他代码（比如异步操作、外部函数）修改，无法确定ptr[next]一定是0，所以不能安全地消除这行代码。

内容的提问来源于stack exchange，提问作者zhanglistar