c++ - 指针追逐基准 : Read+Write(+CLFLUSH) faster than Read(+CLFLUSH)

Question

我正在尝试了解使用 CLFLUSH 对性能的影响。为此，我写了一个小指针追逐基准测试。我拿 std::vector<std::pair<size_t, size_t>>其中第一个元素是下一个条目的偏移量，第二个元素是有效载荷。我从条目 0 转到下一个条目，依此类推，直到到达开头。在路上，我计算了所有有效载荷的总和。

另外，我有两个参数:If write==1 ，我在读取后修改了有效负载(从而使缓存行无效)。如果clflush==1 , 我执行 CLFLUSH在进入下一个元素之前。

vector 的大小等于 L1 缓存的大小 (32 KiB)。

这是我的结果:

write   clflush runtime
0       0       5324060
0       1       298751237
1       0       4366570
1       1       180303091

我确实理解为什么使用 clflush 时运行速度比不使用时慢。但为什么读+写比写快，为什么它看起来比 CLFLUSH 快脏缓存行比干净缓存行？

作为引用，你可以找到我的基准here ，我使用 g++-4.8 -std=c++11 -lrt -O3 编译了它.

Answer 1

这可能不像一个答案，但我不认为您看到的效果是真实的。这是我在 Haswell i7-4770 上使用一些不同的编译器运行您的测试程序时看到的内容:

nate@haswell:~/stack$ chase-g481-orig
write   clflush runtime
0   0   3238411
0   1   55916728
1   0   3220700
1   1   88299263
nate@haswell:~/stack$ chase-icpc-orig
write   clflush runtime
0   0   3226673
0   1   53840185
1   0   4858013
1   1   88143220
nate@haswell:~/stack$ chase-clang-orig
write   clflush runtime
0   0   13521595
0   1   54542441
1   0   3394006
1   1   88344640

它们之间有很多差异，但与您所看到的完全不符。我还在 Sandy Bridge E5-1620 上运行并发现了与这些相似的结果(与你的不匹配)，尽管该机器上的旧版本的 clang++ 没有在 no-write no-flush 情况下爆炸。

首先，您的程序试图使用整个 L1 缓存有点尴尬。如果您可以完全控制系统(在启动时保留 CPU)，这可能是合理的，但它似乎可能会引入混淆效果。如果您的目标是了解这种效果而不是查看缓存在满容量时的行为方式，我建议您将总大小更改为缓存大小的 1/2 或更少。

我认为最可能的解释是，不同的编译器将 clflush 提升到函数中的不同位置，其中一些并没有按照您的预期进行。当你在这个级别工作时，要真正说服编译器做你想做的事情是非常困难的。由于 clflush 内在函数实际上并没有改变结果，因此优化器规则通常会破坏您的意图。

我尝试查看生成的程序集 (objdump -d -C chase)，但无法找到方向。一切都直接内联到 main 中，所以它不仅仅是查看 chase() 函数来查看发生了什么那么简单。使用 -g(用于调试)编译并向 objdump 命令添加 -S(用于源代码)有帮助，但仍然很复杂。我阻止编译器内联的尝试失败了。

如果是我，我会切换到 C 并使用 -fno-inline-functions 进行编译，然后检查是否仍能获得相同的效果。然后剖析 chase() 函数，直到您了解发生了什么。然后用gcc -S输出程序集，修改到顺序正确，看效果是否还在。

还值得注意的是，根据英特尔架构引用手册，clflush 不是序列化指令。即使汇编按照您认为应该的顺序进行，处理器执行之前和之后的指令也是公平的。考虑到你追逐的方式，我认为窗口不够宽，不能成为一个因素，但谁知道呢。您可以通过添加 mfence 来强制序列化。

另一种可能性是 clflush 在您的特定处理器上表现异常。您可以切换使用“wbinvd”的核选项以使所有缓存无效。这是一条很难执行的指令，因为它是“特权”指令，需要由内核执行。你必须写一个 ioctl 来做到这一点。

祝你好运!