Множення матриці: мала різниця у розмірі матриці, велика різниця в термінах

Question 1

У мене є код матричного множення, який виглядає так:

for(i = 0; i < dimension; i++)
    for(j = 0; j < dimension; j++)
        for(k = 0; k < dimension; k++)
            C[dimension*i+j] += A[dimension*i+k] * B[dimension*k+j];

Тут розмір матриці представлений dimension. Тепер, якщо розмір матриць 2000, для запуску цього фрагмента коду потрібно 147 секунд, тоді як якщо розмір матриць 2048, то це займає 447 секунд. Тож, хоча різниці в ні. множення становить (2048 * 2048 * 2048) / (2000 * 2000 * 2000) = 1,073, різниця в термінах складає 447/147 = 3. Хтось може пояснити, чому це трапляється? Я очікував, що масштаб буде лінійним, чого не відбувається. Я не намагаюся зробити найшвидший матричний код множення, просто намагаюся зрозуміти, чому це відбувається.

Технічні характеристики: двоядерний вузол AMD Opteron (2,2 ГГц), 2 ГБ оперативної пам'яті, gcc v 4.5.0

Програма складена як gcc -O3 simple.c

Я також запустив це на компіляторі icc від Intel і бачив подібні результати.

РЕДАГУВАТИ:

Як запропоновано в коментарях / відповідях, я запустив код із розмірністю = 2060, і це займає 145 секунд.

Ось повна програма:

#include <stdlib.h>
#include <stdio.h>
#include <sys/time.h>

/* change dimension size as needed */
const int dimension = 2048;
struct timeval tv; 

double timestamp()
{
        double t;
        gettimeofday(&tv, NULL);
        t = tv.tv_sec + (tv.tv_usec/1000000.0);
        return t;
}

int main(int argc, char *argv[])
{
        int i, j, k;
        double *A, *B, *C, start, end;

        A = (double*)malloc(dimension*dimension*sizeof(double));
        B = (double*)malloc(dimension*dimension*sizeof(double));
        C = (double*)malloc(dimension*dimension*sizeof(double));

        srand(292);

        for(i = 0; i < dimension; i++)
                for(j = 0; j < dimension; j++)
                {   
                        A[dimension*i+j] = (rand()/(RAND_MAX + 1.0));
                        B[dimension*i+j] = (rand()/(RAND_MAX + 1.0));
                        C[dimension*i+j] = 0.0;
                }   

        start = timestamp();
        for(i = 0; i < dimension; i++)
                for(j = 0; j < dimension; j++)
                        for(k = 0; k < dimension; k++)
                                C[dimension*i+j] += A[dimension*i+k] *
                                        B[dimension*k+j];

        end = timestamp();
        printf("\nsecs:%f\n", end-start);

        free(A);
        free(B);
        free(C);

        return 0;
}

Question 2

Ось моя дика здогадка: кеш

Можливо, ви можете помістити doubleв кеш 2 ряди по 2000 с. Що трохи менше, ніж кеш-пам’ять L1 на 32 кб. (поки залишаєте місце інші необхідні речі)

Але коли ви збільшуєте його до 2048 року, він використовує весь кеш (а ви проливаєте трохи, тому що вам потрібно місце для інших речей)

Якщо припустити, що політика кеш-пам'яті є LRU, розливання кешу лише крихітний біт призведе до того, що весь рядок буде багаторазово очищений і перезавантажений в кеш L1.

Інша можливість - асоціативність кеш-пам'яті завдяки силі двох. Хоча я думаю, що процесор є двостороннім асоціативним L1, тому я не думаю, що це має значення в цьому випадку. (але я все одно викину ідею)

Можливе пояснення 2: Пропущено кеш конфлікту через надмірне вирівнювання в кеші L2.

Ваш Bмасив повторюється в стовпці. Тож доступ обмежений. Загальний обсяг даних 2k x 2kстановить приблизно 32 МБ на матрицю. Це набагато більше, ніж ваш кеш L2.

Коли дані не вирівняні ідеально, ви отримаєте пристойну просторову локалізацію на B. Хоча ви перескакуєте рядки і використовуєте лише один елемент для кеш-лінії, кеш-лінія залишається в кеші L2, щоб повторно використовувати її наступною ітерацією середнього циклу.

Однак, коли дані ідеально вирівняні (2048), усі ці стрибки потраплять на один і той самий "шлях кешування" і значно перевищують вашу асоціативність кешу L2. Тому доступні рядки кеш-пам’яті Bне залишатимуться в кеш-пам'яті для наступної ітерації. Натомість їх потрібно буде витягнути з барана.

Question 3

Ви точно отримуєте те, що я називаю кеш- резонансом . Це схоже на псевдонім , але не зовсім те саме. Дозволь пояснити.

Кеші - це апаратні структури даних, які витягують одну частину адреси та використовують її як індекс у таблиці, на відміну від масиву в програмному забезпеченні. (Насправді ми апаратно називаємо їх масивами.) Масив кешу містить рядки кешу даних та теги - іноді один такий запис на індекс у масиві (пряме відображення), іноді кілька таких (асоціативність набору N-шляхів). Другу частину адреси витягують і порівнюють із тегом, що зберігається в масиві. Разом індекс та тег однозначно ідентифікують адресу пам’яті кеш-лінії. Нарешті, решта адресних бітів визначає, які байти в рядку кешу адресуються, разом із розміром доступу.

Зазвичай індекс і тег - це прості бітові поля. Тож адреса пам'яті виглядає так

  ...Tag... | ...Index... | Offset_within_Cache_Line

(Іноді індекс і тег є хешами, наприклад, кілька XOR інших бітів у біти середнього діапазону, які є індексом. Набагато рідше, іноді індекс і рідше тег, - це такі речі, як прийняття адреси рядка кешу за модулем a Просте число. Ці більш складні обчислення індексу - це спроби боротися з проблемою резонансу, яку я поясню тут. Усі страждають певною формою резонансу, але найпростіші схеми вилучення бітового поля мають резонанс на загальних шаблонах доступу, як ви вже знайшли.)

Отже, типові значення ... існує безліч різних моделей "Opteron Dual Core", і я не бачу тут нічого, що вказує, яка саме у вас є. Вибравши навмання, останнє керівництво, яке я бачу на веб-сайті AMD, Посібник розробника Bios і ядра (BKDG) для сімейних моделей AMD 15h 00h-0Fh , 12 березня 2012 р.

(Сімейство 15h = сімейство бульдозерів, найновіший процесор високого класу - BKDG згадує двоядерність, хоча я не знаю номер продукту, який саме ви описуєте. Але, як би там не було, однакова ідея резонансу стосується всіх процесорів, просто такі параметри, як розмір кешу та асоціативність, можуть дещо відрізнятися.)

З стор.33:

Процесор AMD Family 15h містить 16-Кбайтний 4-провідний кеш-пам'ять L1 з двома 128-бітними портами. Це кеш-пам'ять, що підтримує до двох 128 байтних навантажень за цикл. Він розділений на 16 банків, кожен шириною 16 байт. [...] Тільки одне завантаження може бути виконане з даного банку кешу L1 за один цикл.

Підсумовуючи:

64-байтовий рядок кешу => 6 зміщених бітів у рядку кешу
16KB / 4-way => резонанс 4KB.

Тобто біти адреси 0-5 є зміщенням лінії кешу.
Рядки кешу 16KB / 64B => 2 ^ 14/2 ^ 6 = 2 ^ 8 = 256 рядків кешу в кеші.
(Виправлення: спочатку я прорахував це як 128. що я виправив усі залежності.)
4 способи асоціативного => 256/4 = 64 індексу в масиві кешу. Я (Intel) називаю ці "набори".

тобто ви можете розглядати кеш як масив із 32 записів або наборів, кожен запис містить 4 рядки кешу та їх теги. (Це складніше, ніж це, але це нормально).

(До речі, терміни "набір" та "спосіб" мають різні визначення .)

є 6 бітів індексу, біти 6-11 за найпростішою схемою.

Це означає, що будь-які рядки кешу, які мають абсолютно однакові значення в бітах індексу, бітах 6-11, будуть зіставлені з однаковим набором кешу.

А тепер подивіться на свою програму.

C[dimension*i+j] += A[dimension*i+k] * B[dimension*k+j];

Цикл k - це внутрішній цикл. Основний тип - подвійний, 8 байт. Якщо розмір = 2048, тобто 2K, то послідовні елементи, до яких B[dimension*k+j]звертається цикл, будуть складати 2048 * 8 = 16K байт. Всі вони зіставляться з одним і тим же набором кешу L1 - вони всі матимуть однаковий індекс у кеші. Це означає, що замість того, щоб у кеші було 256 рядків кешу, доступних для використання, буде лише 4 - "4-напрямкова асоціативність" кешу.

Тобто ви, мабуть, будете пропускати кеш кожні 4 ітерації навколо цього циклу. Не добре.

(Насправді все трохи складніше. Але вищевказане є першим хорошим розумінням. Адреси записів B, згадані вище, є віртуальними адресами. Отже, можуть бути дещо інші фізичні адреси. Більше того, Bulldozer має спосіб передбачуваного кешу, ймовірно, використовуючи біти віртуальних адрес, щоб йому не довелося чекати перекладу віртуальної на фізичну адресу. Але, у будь-якому випадку: ваш код має "резонанс" 16K. Кеш даних L1 має резонанс 16K. Не добре .)]

Якщо ви трохи зміните розмір, наприклад, на 2048 + 1, тоді адреси масиву B будуть розподілені по всіх наборах кешу. І ви отримаєте значно менше помилок кешу.

Це досить поширена оптимізація підкладання масивів, наприклад, для зміни 2048 на 2049, щоб уникнути цього srt-резонансу. Але "блокування кешу - це ще важливіша оптимізація. Http://suif.stanford.edu/papers/lam-asplos91.pdf

Окрім резонансу лінії кеш-пам'яті, тут діють і інші речі. Наприклад, кеш-пам'ять L1 має 16 банків, кожен шириною 16 байт. Якщо розмірність = 2048, послідовний доступ до B у внутрішньому циклі завжди надходитиме до одного і того ж банку. Отже, вони не можуть пройти паралельно - і якщо доступом A стане той самий банк, ви програєте.

Я не думаю, дивлячись на це, що це таке велике, як резонанс кешу.

І так, можливо, може відбуватися псевдонім. Наприклад, STLF (Store To Load Forwarding buffers), можливо, порівнює лише за допомогою невеликого бітового поля і отримує помилкові збіги.

(Насправді, якщо задуматися, резонанс у кеші схожий на псевдонім, пов’язаний із використанням бітових полів. Резонанс викликаний кількома лініями кешу, що відображають один і той же набір, а не поширюються по колу. біт.)

Загалом, моя рекомендація щодо тюнінгу:

Спробуйте заблокувати кеш без подальшого аналізу. Я кажу це, тому що блокувати кеш легко, і дуже ймовірно, що це все, що вам потрібно було б зробити.
Після цього використовуйте VTune або OProf. Або Cachegrind. Або ...
А ще краще - скористатися добре налаштованою бібліотечною процедурою для множення матриць.

Question 4

Є кілька можливих пояснень. Одне з можливих пояснень полягає в тому, що пропонує Mysticial : вичерпання обмеженого ресурсу (кеш-пам’яті або TLB). Ще однією ймовірною можливістю є помилковий зрив псевдонімів, який може статися, коли послідовні звернення до пам'яті відокремлюються кратним кількома степенями двох (часто 4 КБ).

Ви можете почати звужувати дію, будуючи графік часу / розміру ^ 3 для діапазону значень. Якщо ви продули кеш або вичерпали охоплення TLB, ви побачите більш-менш рівну ділянку, за якою різко підніметься між 2000 і 2048 роками, а потім ще одну плоску секцію. Якщо ви бачите кіоски, пов’язані з псевдонімами, ви побачите більш-менш плоский графік з вузьким стрибком вгору в 2048 році.

Звичайно, це має діагностичну силу, але не є остаточним. Якщо ви хочете остаточно знати, що є джерелом уповільнення, ви захочете дізнатись про лічильники ефективності , які можуть дати остаточну відповідь на подібне запитання.

Question 5

Я знаю, що це занадто давно, але я перекушу. Це (як уже було сказано) проблема з кешем, що спричиняє уповільнення приблизно на рівні двох. Але з цим є ще одна проблема: це занадто повільно. Якщо ви подивитесь на ваш цикл обчислень.

for(i = 0; i < dimension; i++)
    for(j = 0; j < dimension; j++)
        for(k = 0; k < dimension; k++)
            C[dimension*i+j] += A[dimension*i+k] * B[dimension*k+j];

Найбільш внутрішній цикл змінює k на 1 кожну ітерацію, це означає, що ви отримуєте доступ лише до 1 подвоєного від останнього елемента, який ви використовували з A, але цілий "вимір" подвоюється від останнього елемента B. Це не використовує жодних переваг кешування елементів B.

Якщо ви зміните це на:

for(i = 0; i < dimension; i++)
    for(j = 0; j < dimension; j++)
        for(k = 0; k < dimension; k++)
            C[dimension*i+k] += A[dimension*i+j] * B[dimension*j+k];

Ви отримуєте абсолютно однакові результати (по модулю помилки асоціативності подвійного додавання), але це набагато зручніше кеш-пам’яті ( локальне ). Я спробував, і це дає суттєві покращення. Це можна узагальнити як

Не множте матриці за визначенням, а скоріше за рядками

Приклад прискорення (я змінив ваш код, щоб взяти розмір як аргумент)

$ diff a.c b.c
42c42
<               C[dimension*i+j] += A[dimension*i+k] * B[dimension*k+j];
---
>               C[dimension*i+k] += A[dimension*i+j] * B[dimension*j+k];
$ make a
cc     a.c   -o a
$ make b
cc     b.c   -o b
$ ./a 1024

secs:88.732918
$ ./b 1024

secs:12.116630

Як бонус (і що пов’язано з цим питанням) є те, що цей цикл не страждає від попередньої проблеми.

Якщо ви вже все це знали, то я перепрошую!

Question 6

Кілька відповідей згадували проблеми L2 Cache.

Ви можете перевірити це за допомогою моделювання кешу . Це може зробити інструмент кешгринда Valgrind .

valgrind --tool=cachegrind --cache-sim=yes your_executable

Встановіть параметри командного рядка так, щоб вони відповідали параметрам L2 вашого процесора.

Перевірте його з різними розмірами матриці, ви, ймовірно, побачите раптове збільшення коефіцієнта пропуску L2.