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

Вдохновленный этот недавний вопрос о SO и ответы, данные, что заставило меня чувствовать себя очень невежественным, я решил потратить некоторое время, чтобы узнать больше о Кеширование процессора и написал небольшую программу, чтобы проверить, правильно ли я все понимаю (скорее всего, нет, я боюсь). Я сначала запишу допущения это лежит в основе моих ожиданий, так что вы могли бы остановить меня здесь, если это не так. Основываясь на том, что я прочитал, в общем:

1. nАссоциативный кэш делится на s наборы, каждый из которых содержит n строки, каждая строка имеет фиксированный размер L;
2. Каждый адрес основной памяти A может быть сопоставлен с любой из n строки кэша один задавать;
3. Набор на какой адрес A сопоставление можно найти, разбив адресное пространство на слоты, каждый из которых имеет размер в одну строку кэша, а затем вычислив индекс Aслот (I = A / L) и, наконец, выполнить операцию по модулю для сопоставления индекса с целевым набором T (T = I % s);
4. Задержка чтения из кеша приводит к более высокой задержке, чем пропущенная запись в кеш, потому что ЦП с меньшей вероятностью будет зависать и бездействовать, ожидая выборки строки основной памяти.

Мой первый вопрос: эти предположения верны?

Предполагая, что они есть, я попытался немного поиграть с этими концепциями, чтобы я мог на самом деле увидеть они оказывают конкретное влияние на программу. Я написал простой тест, который выделяет буфер памяти B байты и неоднократно обращаются к местоположениям этого буфера с фиксированные приращения данного шаг с начала буфера (имеется в виду, что если B 14 и шаг 3, я неоднократно посещаю только места 0, 3, 6, 9 и 12 — и то же самое верно, если B 13, 14 или 15):

int index = 0;
for (int i = 0; i < REPS; i++)
{
index += STEP;
if (index >= B) { index = 0; }
buffer[index] = ...; // Do something here!
}

Из-за вышеизложенных предположений мои ожидания были следующими:

1. При настройке STEP равный критический шаг (то есть размер строки кэша, умноженный на число наборов в кэше, или L * s), производительность должна быть значительно хуже чем когда STEP устанавливается, например, (L * s) + 1потому что мы будем иметь доступ только к тем областям памяти, которые отображаются в так же установить, заставляя строку кеша чаще исключаться из этого набора и приводя к более высокой частоте пропадания кеша;
2. когда STEP равно критическому шагу, производительности не должно быть затронуто по размеру B буфера, если он не слишком мал (в противном случае будет посещено слишком мало мест и будет меньше пропусков кеша); в противном случае, производительность должны быть затронуты от Bпотому что с большим буфером у нас больше шансов получить доступ к местоположениям, которые отображаются в разных наборах (особенно если STEP не кратно 2);
3. Производительность потеря должно быть хуже при чтении из а также писать в каждое расположение буфера чем когда только пишу в эти местоположения: запись в ячейку памяти не должна требовать ожидания соответствующей строки, поэтому факт доступа к ячейкам памяти, которые отображаются в один и тот же набор (опять же, с использованием критического шага как STEP) должен иметь незначительное влияние.

Так что я использовал RightMark Memory Analyzer чтобы выяснить параметры моего кэша данных L1 CPU, настроил размеры в моей программе и опробовал его. Вот так я написал основной цикл (onlyWriteToCache это флаг, который можно установить из командной строки):

    ...
for (int i = 0; i < REPS; i++)
{
...
if (onlyWriteToCache)
{
buffer[index] = (char)(index % 255);
}
else
{
buffer[index] = (char)(buffer[index] % 255);
}
}

исход короче:

• Ожидания 1) и 2) подтвердились;
• Ожидание 3) было не подтверждено.

Этот факт поражает меня и заставляет думать, что я не совсем правильно понял. когда B 256 МБ и STEP равно критическому шагу, тест (скомпилированный с -O3 в GCC 4.7.1) показывает, что:

• Версия цикла только для записи страдает от среднего ~ 6х потеря производительности (6,234 с против 1,078 с);
• Версия цикла чтения-записи страдает от среднего ~ 1.3x потеря производительности (6,671 с против 5,25 с).

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

Для полноты ниже приведена программа, которую я написал для выполнения тестов, где константы отражают аппаратные параметры моей машины: размер L1 8-way ассоциативного кеш данных это 32 кб и размер L каждой строки кэша составляет 64 байта, что дает в общей сложности 64 набора (ЦП имеет отдельный 8-канальный кэш инструкций L1 того же размера и с идентичным размером строки).

#include <iostream>
#include <ctime>
#include <cstdlib>
#include <iterator>
#include <algorithm>

using namespace std;

// Auxiliary functions

constexpr int pow(int base, int exp)
{
return ((exp == 0) ? 1 : base * pow(base, exp - 1));
}

int main(int argc, char* argv[])
{
//======================================================================
// Define behavior from command-line arguments
//======================================================================

bool useCriticalStep = false;
bool onlyWriteToCache = true;
size_t BUFFER_SIZE = pow(2, 28);
size_t REPS = pow(2, 27);

if (argc > 0)
{
for (int i = 1; i < argc; i++)
{
string option = argv[i];
if (option == "-c")
{
useCriticalStep = true;
}
else if (option == "-r")
{
onlyWriteToCache = false;
}
else if (option[1] == 's')
{
string encodedSizeInMB = option.substr(2);
size_t sizeInMB = atoi(encodedSizeInMB.c_str());
BUFFER_SIZE = sizeInMB * pow(2, 20);
}
else if (option[1] == 'f')
{
string encodedNumOfReps = option.substr(2);
size_t millionsOfReps = atoi(encodedNumOfReps.c_str());
REPS = millionsOfReps * pow(10, 6);
}
}
}

//======================================================================
// Machine parameters
//======================================================================

constexpr int CACHE_SIZE = pow(2, 15);
constexpr int CACHE_LINE_SIZE = 64;
constexpr int CACHE_LINES_PER_SET = 8;
constexpr int SET_SIZE = CACHE_LINE_SIZE * CACHE_LINES_PER_SET;
constexpr int NUM_OF_SETS = CACHE_SIZE / SET_SIZE;

//======================================================================
// Print out the machine parameters
//======================================================================

cout << "CACHE SIZE: " << CACHE_SIZE / 1024 << " KB" << endl;
cout << "CACHE LINE SIZE: " << CACHE_LINE_SIZE << " bytes" << endl;
cout << "CACHE LINES PER SET: " << CACHE_LINES_PER_SET << endl;
cout << "SET SIZE: " << SET_SIZE << " bytes" << endl;
cout << "NUMBER OF SETS: " << NUM_OF_SETS << endl;

fill_n(ostream_iterator<char>(cout), 30, '='); cout << endl;

//======================================================================
// Test parameters
//======================================================================

const int STEP = NUM_OF_SETS * CACHE_LINE_SIZE + (useCriticalStep ? 0 : 1);

//======================================================================
// Print out the machine parameters
//======================================================================

cout << "BUFFER SIZE: " << BUFFER_SIZE / pow(2, 20) << " MB" << endl;
cout << "STEP SIZE: " << STEP << " bytes" << endl;
cout << "NUMBER OF REPS: " << REPS << endl;

fill_n(ostream_iterator<char>(cout), 30, '='); cout << endl;

//======================================================================
// Start the test
//======================================================================

char* buffer = new char[BUFFER_SIZE];

clock_t t1 = clock();

int index = 0;
for (size_t i = 0; i < REPS; i++)
{
index += STEP;
if (index >= BUFFER_SIZE)
{
index = 0;
}

if (onlyWriteToCache)
{
buffer[index] = (char)(index % 255);
}
else
{
buffer[index] = (char)(buffer[index] % 255);
}
}

clock_t t2 = clock();

//======================================================================
// Print the execution time (in clock ticks) and cleanup resources
//======================================================================

float executionTime = (float)(t2 - t1) / CLOCKS_PER_SEC;
cout << "EXECUTION TIME: " << executionTime << "s" << endl;

delete[] buffer;
}

Заранее спасибо, если вам удалось прочитать этот длинный вопрос.