Объяснение этого поведения производительности кэшей процессора

Я пытаюсь воспроизвести результаты, представленные здесь Что каждый программист должен знать о памяти, в частности, результаты, показанные на следующем рисунке (стр. 20-21 в статье)

Влияние размеров кеша

что в основном представляет собой график циклов на элемент для разных рабочих размеров, внезапные подъемы на графике происходят в точках, где размер рабочего набора превышает размер кэша.

Для этого я написал это код здесь. Я вижу, что со всеми данными, извлекаемыми из памяти (путем очистки кэша каждый раз с использованием clflush), производительность
одинаково для всех размеров данных (как и ожидалось), но с кешами в действии я вижу полностью
противоположная тенденция


Working Set: 16 Kb took 72.62 ticks per access
Working Set: 32 Kb took 46.31 ticks per access
Working Set: 64 Kb took 28.19 ticks per access
Working Set: 128 Kb took 23.70 ticks per access
Working Set: 256 Kb took 20.92 ticks per access
Working Set: 512 Kb took 35.07 ticks per access
Working Set: 1024 Kb took 24.59 ticks per access
Working Set: 2048 Kb took 24.44 ticks per access
Working Set: 3072 Kb took 24.70 ticks per access
Working Set: 4096 Kb took 22.17 ticks per access
Working Set: 5120 Kb took 21.90 ticks per access
Working Set: 6144 Kb took 23.29 ticks per access

Может кто-нибудь объяснить это поведение. Я полагаю, что «предварительная выборка» хорошо справляется со своей задачей, доставляя данные в кэш в начале конвейера.

Если так, как я могу воспроизвести наблюдения, показанные на графике?
Размеры моего кэша: L1 (32 КБ), L2 (256 КБ) и L3 (3072 КБ).

Спасибо

6

Решение

Вот мой модифицированный код. Это шаг за STEP байт каждый раз, обновляя память. Я выбрал STEP чтобы соответствовать размеру строки кэша моего процессора (64 байта). Повторяет цикл заполнения REPEAT раз. Он записывает один байт в каждую строку кэша.

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#define ARRAYSIZE(arr) (sizeof(arr)/sizeof(arr[0]))

#define STEP (64)
#define REPEAT (1000)

inline void
clflush(volatile void *p)
{
asm volatile ("clflush (%0)" :: "r"(p));
}

inline uint64_t
rdtsc()
{
unsigned long a, d;
asm volatile ("cpuid; rdtsc" : "=a" (a), "=d" (d) : : "ebx", "ecx");
return a | ((uint64_t)d << 32);
}

//volatile int i;volatile unsigned char data[1 << 26]; // 64MBvoid sequentialAccess(int bytes)
{
for (int j = 0; j < REPEAT; j++)
for (int i = 0; i < bytes; i += STEP)
data[i] = i;

}

int rangeArr[] = {16, 32, 64, 128, 256, 512, 1024, 2048, 3072, 4096, 6144, 8192, 10240, 12*1024, 14*1024, 16*1024};

inline void test()
{
for (int i = 0; i < ARRAYSIZE(rangeArr); i++)
{
uint64_t start, end;
int kilobytes = rangeArr[i];
start = rdtsc();
sequentialAccess(kilobytes * 1024);
end = rdtsc();
double ticksPerAccess = 1.0 * (end - start) / (kilobytes * 1024 / STEP) / REPEAT;
printf("%d kB took %lf ticks per access\n", kilobytes, ticksPerAccess);
}
}

int
main(int ac, char **av)
{
test();
return 0;
}

На моем «Процессоре AMD Phenom ™ II X4 965» (строка из /proc/cpuinfo), Я получил следующие результаты:

16 kB took 9.148758 ticks per access
32 kB took 8.855980 ticks per access
64 kB took 9.008148 ticks per access
128 kB took 17.197035 ticks per access
256 kB took 14.416313 ticks per access
512 kB took 15.845552 ticks per access
1024 kB took 21.394375 ticks per access
2048 kB took 21.379112 ticks per access
3072 kB took 21.399206 ticks per access
4096 kB took 21.630234 ticks per access
6144 kB took 23.907972 ticks per access
8192 kB took 46.306525 ticks per access
10240 kB took 49.292271 ticks per access
12288 kB took 49.575894 ticks per access
14336 kB took 49.758874 ticks per access
16384 kB took 49.660779 ticks per access

Это немного больше похоже на кривую Ульриха.


редактироватьПосле более тщательного изучения исходного эталонного теста Ульриха Дреппера я понял, что он создает связанный список за пределами области измерения, а затем измеряет стоимость отслеживания этого связанного списка. Это измеряет параметр, называемый «нагрузка для использования задержки», и это очень полезный параметр для извлечения из системы памяти.

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

В коде ниже, вы можете настроить NPAD чтобы соответствовать размеру строки кэша вашего процессора. Вы можете настроить ACCESSES контролировать количество итераций цикла бенчмарка. Общее количество итераций полностью не зависит от размера набора данных.

Код:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#define NPAD (64 - sizeof(void *))
#define ACCESSES (1 << 28)inline void
clflush(volatile void *p)
{
asm volatile ("clflush (%0)" :: "r"(p));
}

inline uint64_t
rdtsc()
{
unsigned long a, d;
asm volatile ("cpuid; rdtsc" : "=a" (a), "=d" (d) : : "ebx", "ecx");
return a | ((uint64_t)d << 32);
}struct l
{
l    *next;
char pad[NPAD];
};l array[ (1 << 26) / sizeof(l) ];void init_sequential(int bytes)
{
int elems = bytes / sizeof(l);

for (int i = 1; i < elems; i++)
{
array[i - 1].next = &array[i];
}

array[elems - 1].next = &array[0];
}

void measure_baseline( int accesses )
{
volatile l *ptr = &array[0];

while (accesses-- > 0)
ptr = ptr->next;
}int rangeArr[] = {16, 32, 64, 128, 256, 512, 1024, 2048, 3072, 4096, 6144, 8192, 10240, 12*1024, 14*1024, 16*1024};

inline void test()
{
for (int i = 0; i < sizeof(rangeArr) / sizeof(rangeArr[0]); i++)
{
uint64_t start, end;
int kilobytes = rangeArr[i];

init_sequential( kilobytes * 1024 );

start = rdtsc();
measure_baseline( ACCESSES );
end = rdtsc();
double ticksPerAccess = 1.0 * (end - start) / ACCESSES;
printf("%d kB took %lf ticks per access\n", kilobytes, ticksPerAccess);
}
}

int
main(int ac, char **av)
{
test();
return 0;
}

А вот данные, собранные с моего процессора:

16 kB took 3.062668 ticks per access
32 kB took 3.002012 ticks per access
64 kB took 3.001376 ticks per access
128 kB took 9.204764 ticks per access
256 kB took 9.284414 ticks per access
512 kB took 15.848642 ticks per access
1024 kB took 22.645605 ticks per access
2048 kB took 22.698062 ticks per access
3072 kB took 23.039498 ticks per access
4096 kB took 23.481494 ticks per access
6144 kB took 37.720315 ticks per access
8192 kB took 55.197783 ticks per access
10240 kB took 55.886692 ticks per access
12288 kB took 56.262199 ticks per access
14336 kB took 56.153559 ticks per access
16384 kB took 55.879395 ticks per access

Это показывает 3-тактную загрузку для использования задержки для данных в L1D, что я ожидаю от этого процессора (и большинства основных высокопроизводительных процессоров, ориентированных на ПК).

5

Другие решения

Причина ваших результатов довольно проста. Вы думаете, что оперируете килобайтами, но это не так. Если вы заявляете, что тестируете 16 КБ, вы на самом деле тестируете только 16 записей по четыре или восемь байтов. Таким образом, кеши вообще не входят в это, и вы измеряете время для простого доступа, плюс накладные расходы на измерение, деленные на 16, 32, 64 и т. Д.

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

0

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector