Почему обработка нескольких потоков данных медленнее, чем обработка одного?

Я тестирую, как чтение нескольких потоков данных влияет на производительность кэширования ЦП. Я использую следующий код для сравнения. Тест считывает целые числа, хранящиеся последовательно в памяти, и записывает частичные суммы обратно последовательно. Количество последовательных блоков, которые считываются, варьируется. Целые числа из блоков читаются в циклическом порядке.

#include <iostream>
#include <vector>
#include <chrono>
using std::vector;
void test_with_split(int num_arrays) {
int num_values = 100000000;
// Fix up the number of values. The effect of this should be insignificant.
num_values -= (num_values % num_arrays);
int num_values_per_array = num_values / num_arrays;
// Initialize data to process
auto results = vector<int>(num_values);
auto arrays = vector<vector<int>>(num_arrays);
for (int i = 0; i < num_arrays; ++i) {
arrays.emplace_back(num_values_per_array);
}
for (int i = 0; i < num_values; ++i) {
arrays[i%num_arrays].emplace_back(i);
results.emplace_back(0);
}
// Try to clear the cache
const int size = 20*1024*1024; // Allocate 20M. Set much larger then L2
char *c = (char *)malloc(size);
for (int i = 0; i < 100; i++)
for (int j = 0; j < size; j++)
c[j] = i*j;
free(c);
auto start = std::chrono::high_resolution_clock::now();
// Do the processing
int sum = 0;
for (int i = 0; i < num_values; ++i) {
sum += arrays[i%num_arrays][i/num_arrays];
results[i] = sum;
}
std::cout << "Time with " << num_arrays << " arrays: " << std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now() - start).count() << " ms\n";
}
int main() {
int num_arrays = 1;
while (true) {
test_with_split(num_arrays++);
}
}

Вот моменты времени для разделения 1-80 тактов на процессоре Intel Core 2 Quad Q9550 с частотой 2,83 ГГц:

Увеличение скорости вскоре после 8 потоков имеет смысл для меня, так как процессор имеет 8-сторонний ассоциативный кэш L1. 24-сторонний ассоциативный кэш L2, в свою очередь, объясняет рост 24 потоков. Это особенно верно, если я получаю те же эффекты, что и в Почему один цикл намного медленнее двух?, где несколько больших распределений всегда оказываются в одном наборе ассоциативности. Для сравнения я включил в конце времени, когда распределение сделано в одном большом блоке.

Тем не менее, я не полностью понимаю удар от одного потока до двух потоков. Я думаю, что это как-то связано с предварительной загрузкой в ​​кэш L1. Чтение Справочное руководство по оптимизации архитектур Intel 64 и IA-32 кажется, что потоковый предварительный выборщик L2 поддерживает отслеживание до 32 потоков данных, но такая информация не предоставляется для потокового предварительного выборщика L1. Префиксер L1 не может отслеживать несколько потоков, или здесь есть что-то еще?

Фон

Я исследую это, потому что хочу понять, как организация сущностей в игровом движке как компонентов в стиле структуры массивов влияет на производительность. На данный момент кажется, что данные, необходимые для преобразования, состоящего из двух компонентов по сравнению с 8-10 компонентами, не будут иметь большого значения для современных процессоров. Однако приведенное выше тестирование показывает, что иногда имеет смысл избегать разбиения некоторых данных на несколько компонентов, если это позволит преобразованию с «узкими местами» использовать только один компонент, даже если это означает, что какое-то другое преобразование должно будет считывать данные. не заинтересованы в.

Выделение в одном блоке

Вот временные интервалы, если вместо того, чтобы выделять несколько блоков данных, только один выделяется и к нему обращаются пошагово. Это не меняет удар от одного потока к двум, но я включил его для полноты картины.

И вот модифицированный код для этого:

void test_with_split(int num_arrays) {
int num_values = 100000000;
num_values -= (num_values % num_arrays);
int num_values_per_array = num_values / num_arrays;

// Initialize data to process
auto results = vector<int>(num_values);
auto array = vector<int>(num_values);
for (int i = 0; i < num_values; ++i) {
array.emplace_back(i);
results.emplace_back(0);
}

// Try to clear the cache
const int size = 20*1024*1024; // Allocate 20M. Set much larger then L2
char *c = (char *)malloc(size);
for (int i = 0; i < 100; i++)
for (int j = 0; j < size; j++)
c[j] = i*j;
free(c);

auto start = std::chrono::high_resolution_clock::now();
// Do the processing
int sum = 0;
for (int i = 0; i < num_values; ++i) {
sum += array[(i%num_arrays)*num_values_per_array+i/num_arrays];
results[i] = sum;
}
std::cout << "Time with " << num_arrays << " arrays: " << std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now() - start).count() << " ms\n";
}

Редактировать 1

Я убедился, что различие между 1 и 2 не связано с тем, что компилятор развернул цикл и по-разному оптимизировал первую итерацию. С использованием __attribute__ ((noinline)) Я убедился, что рабочая функция не встроена в основную функцию. Я проверил, что это не произошло, посмотрев на сгенерированную сборку. Время после этих изменений было одинаковым.