2013-12-15 3 views
6

Я пытаюсь воспроизвести результаты, представленные здесь What Every programmer should know about memory, в частности, результаты, показанные на следующем рисунке (p20-21 в бумаге)Объяснение такого поведения производительности CPU кэширует

Impact of cache sizes

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

Для этого я написал это code here. Я вижу, что, когда все данные извлекаются из памяти (путем кратковременного сброса кеша при использовании 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 Кб).

Спасибо

+0

Это, безусловно, похоже на предварительную выборку, это хорошая работа. Какой процессор, BTW? Intel? AMD? Модель? –

+0

x86_64, intel i5 – sud03r

+0

Я только что запустил ваш код на своем процессоре AMD Phenom x4 и получил аналогичные результаты. Мне нужно было внести некоторые незначительные изменения, чтобы скомпилировать его. (Например, я удалил 'volatile int i', и я положил' for (j = 0; j <10000; j ++) 'вокруг цикла последовательного доступа.) –

ответ

5

Вот мой модифицированный код. Он каждый раз выполняет 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]; // 64MB 


void 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 (TM) II X4 965 Processor" (строка из /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 

Это выглядит немного больше похоже на кривой Ульриха.


Редактировать: При ближайшем рассмотрении первоначального ориентира Ульриха Drepper, я понял, что он строит связанный список вне области измерения, а затем измерения стоимости чеканки, что связанный список. Это измеряет параметр, называемый «load to use latency», и это очень полезный параметр для извлечения из системы памяти.

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

В приведенном ниже коде вы можете настроить 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, что я ожидаю для этого процессор (и большинство основных высокопроизводительных процессоров с ПК).

+0

Спасибо за ваш ответ, мои результаты выглядят следующим образом: 16 Kb -> 18.90, 32 Kb -> 18.07, 64 Kb -> 16.61, 128 Kb -> 11.57, 256 Kb -> 12.62, 512 Kb -> 14.25, 1024 Kb -> 14.36, 2048 Kb -> 14.51, 3072 Kb -> 15.38, 4096 Kb -> 16.52, 6144 Kb -> 18.06, 8192 Kb -> 18.88, 10240 Kb -> 19.41, 12288 Кб -> 20.00, 14336 Кб -> 20.06, 16384 Kb -> 20.73 – sud03r

+0

@ sud03r: BTW, присоединяйтесь к нам в чате. Код и данные по этой ссылке более соответствуют духу того, что измерял Ульрих: http://spatula-city.org/~im14u2c/cache/ –

+0

Спасибо за ваши усилия, я получил его и, наконец, смог воспроизвести результаты на моем конец. Большое спасибо! – sud03r

0

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

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

Смежные вопросы