多次运行之间同一程序的不同缓存未命中计数

Question

我正在使用 Cachegrind 来检索没有 libc 编译的静态程序的缓存未命中次数（只是_start调用我的主函数和 asm 中的退出系统调用）。该程序是完全确定性的，指令和内存引用不会从一次运行到另一次运行发生变化。缓存与LRU完全关联作为替换策略。

然而，我注意到失误的数量有时会发生变化。更具体地说，在我转到不同的目录之前，未命中的次数始终相同：

 % cache=8 && valgrind --tool=cachegrind --I1=$((cache * 64)),$cache,64 --D1=$((cache * 64)),$cache,64 --L2=262144,4096,64 ./adpcm        
 ...
 ==31352== I   refs:      216,145,010
 ...
 ==31352== D   refs:      130,481,003  (95,186,001 rd   + 35,295,002 wr)
 ==31352== D1  misses:        240,004  (   150,000 rd   +     90,004 wr)
 ==31352== LLd misses:             31  (        11 rd   +         20 wr)

如果我一次又一次地执行相同的命令，我将继续得到相同的结果。但是如果我从不同的目录运行这个程序：

 % cd ..
 % cache=8 && valgrind --tool=cachegrind --I1=$((cache * 64)),$cache,64 --D1=$((cache * 64)),$cache,64 --L2=262144,4096,64 ./malardalen2/adpcm
 ...
 ==31531== I   refs:      216,145,010
 ...
 ==31531== D   refs:      130,481,003  (95,186,001 rd   + 35,295,002 wr)
 ==31531== D1  misses:        250,004  (   160,000 rd   +     90,004 wr)
 ==31531== LLd misses:             31  (        11 rd   +         20 wr)

我什至从不同的目录得到了不同的结果。

我还使用 Pin 工具做了一些实验，使用这个工具我不需要更改目录来获取不同的值。但似乎可能的值集非常有限，并且与 Cachegrind 完全相同。

我的问题是：这种差异的根源是什么？

我的第一个提示是，我的程序在内存中的对齐方式不同，因此，先前运行中存储在同一行中的某些变量不再存在。这也可以解释组合数量有限的原因。但我认为cachegrind（和Pin）正在使用虚拟地址，并且我假设操作系统（Linux）总是给出相同的虚拟地址。还有其他想法吗？

编辑：正如您可以猜测读取 LLd 未命中，该程序仅使用 31 个不同的缓存行。此外，高速缓存只能包含 8 个高速缓存行。因此，即使实际上，这种差异也不能用第二次填充缓存的想法来解释（最多只有 8 行可以保留在 L1 中）。

编辑2： Cachegrind 的报告不是基于实际的缓存未命中（由性能计数器给出），而是模拟的结果。基本上，它模拟缓存的行为以计算未命中的次数。由于结果只是暂时的，所以完全没问题，并且允许更改缓存属性（大小、关联性）。

编辑 3：我使用的硬件是 Linux 3.2 x86_64 上的 Intel Core i7。编译标志是 -static ，对于某些程序是 -nostdlib （IIRC，我现在不在家）。

Answer 1

出于安全考虑，Linux 实现了“地址空间布局随机化”技术 ( http://en.wikipedia.org/wiki/Address_space_layout_randomization )。您可以像这样停用此行为：

echo -n "0" > /proc/sys/kernel/randomize_va_space

您可以通过以下示例进行测试：

#include <stdio.h>

int main() {
   char a;
   printf("%u\n", &a);
   return 0;
}

您应该始终打印相同的值。

前：

 % ./a.out
4006500239
 % ./a.out
819175583
 % ./a.out
2443759599
 % ./a.out
2432498159

后：

 % ./a.out
4294960207
 % ./a.out
4294960207
 % ./a.out
4294960207
 % ./a.out
4294960207

这也解释了不同数量的缓存未命中，因为同一行中的两个变量现在可以位于两个不同的行中。

编辑：这显然并不能完全解决问题，但我认为这是原因之一。我将向任何可以帮助我解决此问题的人提供赏金。