Различное количество промахов кеша для одной и той же программы между несколькими запусками

В 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

Это также объясняет различное количество промахов кеша, поскольку две переменные, которые были в одной строке, теперь могут быть в двух разных строках.

Редактировать: Это, по-видимому, не решает проблему полностью, но я думаю, что это было одной из причин. Я дам награду любому, кто может помочь мне решить эту проблему.

Кажется, это известное поведение в valgrind:

Я использовал пример, который выводит базовый адрес кеша, также я отключил рандомизацию макета.

Я дважды запускал исполняемый файл, получая одинаковые результаты в обоих запусках:

D   refs:       40,649  (28,565 rd   + 12,084 wr)
==15016== D1  misses:     11,465  ( 8,412 rd   +  3,053 wr)
==15016== LLd misses:      1,516  ( 1,052 rd   +    464 wr)
==15016== D1  miss rate:    28.2% (  29.4%     +   25.2%  )
==15016== LLd miss rate:     3.7% (   3.6%     +    3.8%  )

villar@localhost ~ $ cache=8 && valgrind --tool=cachegrind --I1=$((cache * 64)),$cache,64 --D1=$((cache * 64)),$cache,64 --L2=262144,4096,64 ./a.out 

==15019== D   refs:       40,649  (28,565 rd   + 12,084 wr)
==15019== D1  misses:     11,465  ( 8,412 rd   +  3,053 wr)
==15019== LLd misses:      1,516  ( 1,052 rd   +    464 wr)
==15019== D1  miss rate:    28.2% (  29.4%     +   25.2%  )
==15019== LLd miss rate:     3.7% (   3.6%     +    3.8%  )

Согласно документации cachegrind (http://www.cs.washington.edu/education/courses/cse326/05wi/valgrind-doc/cg_main.html)

Еще одна вещь ничего не стоит, это то, что результаты очень чувствительны. Изменение размера файла >valgrind.so, размера профилируемой программы, или даже длины ее имени может исказить результаты. Вариации будут небольшими, но не ожидайте идеально повторяющихся результатов, если ваша программа вообще изменится. Хотя эти факторы означают, что вы не должны доверять результатам, чтобы быть сверхточными, мы надеемся, что они должны быть достаточно близкими, чтобы быть полезными.

Прочитав это, я изменил имя файла и получил следующее:

villar@localhost ~ $ mv a.out a.out2345345345
villar@localhost ~ $ cache=8 && valgrind --tool=cachegrind --I1=$((cache * 64)),$cache,64 --D1=$((cache * 64)),$cache,64 --L2=262144,4096,64 ./a.out2345345345 

==15022== D   refs:       40,652  (28,567 rd   + 12,085 wr)
==15022== D1  misses:     10,737  ( 8,201 rd   +  2,536 wr)
==15022== LLd misses:      1,517  ( 1,054 rd   +    463 wr)
==15022== D1  miss rate:    26.4% (  28.7%     +   20.9%  )
==15022== LLd miss rate:     3.7% (   3.6%     +    3.8%  )

Изменение имени обратно на «a.out» дало мне точно такой же результат, как и раньше.

Обратите внимание, что изменение имени файла или пути к нему изменит базу стека!! и это может быть причиной после прочтения того, что сказал г-н Евгений в предыдущем комментарии

Когда вы меняете текущий рабочий каталог, вы также меняете соответствующую переменную среды (и ее длину). Поскольку копия всех переменных среды обычно хранится непосредственно над стеком, вы получаете другое распределение для переменных стека и разное количество промахов кэша. (И оболочка может изменить некоторые другие переменные, кроме "PWD").

РЕДАКТИРОВАТЬ: В документации также говорится:

Запуск/закрытие программы вызывает множество функций, которые не интересны и только усложняют вывод. Было бы неплохо их как-то исключить.

Моделируемый кеш может отслеживать начало и конец программы, являясь источником изменений.