Почему ускорение ниже ожидаемого с помощью AVX2?

Question

Я векторизовал внутренний цикл добавления матрицы, используя инструкцию intrinsics для AVX2, у меня также есть таблица задержек от here. Я ожидаю, что ускорение должно быть в 5 раз, потому что почти 4 задержки происходят в 1024 итерациях более 6 латентностей в 128 итерациях, но ускорение является фактором 3, поэтому вопрос заключается в том, что еще здесь, чего я не вижу. Я использую gcc, кодирование в c, intrinsics, CPU - skylake 6700hq

Вот c и сборка из внутренней петли.

глобальные данные:

int __attribute__((aligned(32))) a[MAX1][MAX2] ; 
int __attribute__((aligned(32))) b[MAX2][MAX3] ; 
int __attribute__((aligned(32))) c_result[MAX1][MAX3] ; 

последовательные:

for(i = 0 ; i < MAX1 ; i++) 
     for(j = 0 ; j < MAX2 ; j++) 
      c_result[i][j] = a[i][j] + b[i][j]; 

.L16: 
    movl (%r9,%rax), %edx   // latency : 2 , throughput : 0.5 number of execution unit : 4 ALU 
    addl (%r8,%rax), %edx   // latency : dont know , throughput : 0.5  number of execution unit : 4 ALU 
    movl %edx, c_result(%rcx,%rax) // latency : 2 , throughput : 1 number of execution unit : 4 ALU 
    addq $4, %rax 
    cmpq $4096, %rax 
    jne .L16 

AVX2:

for(i = 0 ; i < MAX1 ; i++){ 
    for(j = 0 ; j < MAX2 ; j += 8){ 
     a0_i= _mm256_add_epi32(_mm256_load_si256((__m256i *)&a[i][j]) , _mm256_load_si256((__m256i *)&b[i][j])); 
      _mm256_store_si256((__m256i *)&c_result[i][j], a0_i); 
    }} 

.L22: 
    vmovdqa (%rcx,%rax), %ymm0   // latency : 3 , throughput : 0.5  number of execution unit : 4 ALU 
    vpaddd (%r8,%rax), %ymm0, %ymm0  // latency : dont know , throughput : 0.5 number of execution unit : 3 VEC-ALU 
    vmovdqa %ymm0, c_result(%rdx,%rax) // latency : 3 , throughput : 1 number of execution unit : 4 ALU 
    addq $32, %rax 
    cmpq $4096, %rax 
    jne .L22 

Answer 1

Другие, чем счетчик цикла, нет никакой цепи зависимостей петли несут. Таким образом, операции с разных итераций цикла могут быть в полете сразу. Это означает, что латентность не является узким местом, а просто пропускной способностью (исполнительных блоков и интерфейсом (до 4 подключений с плавным доменом на каждый такт)).

Кроме того, ваши номера абсолютно безумны. mov Нагрузки не принимают 4 исполнительных блока ALU! И числа задержки загрузки/хранения ошибочны/бессмысленны (см. Последний раздел).

# Scalar (serial is the wrong word. Both versions are serial, not parallel) 
.L16: 
    movl (%r9,%rax), %edx   // fused-domain uops: 1. Unfused domain: a load port 
    addl (%r8,%rax), %edx   // fused-domain uops: 2 Unfused domain: a load port and any ALU port 
    movl %edx, c_result(%rcx,%rax) // fused-domain uops: 2 Unfused domain: store-address and store-data ports. port7 can't handle 2-reg addresses 
    addq $4, %rax     // fused-domain uops: 1 unfused: any ALU 
    cmpq $4096, %rax    // fused-domain uops: 0 (fused with jcc) 
    jne .L16       // fused-domain uops: 1 unfused: port6 (predicted-taken branch) 

Итого: 7 слита-домен микрооперация означает, что цикл может выдавать из буфера петли на одной итерации на 2с. (не на 1,75 в). Поскольку мы используем сочетание загрузок, хранилищ и модулей ALU, порты выполнения не являются узким местом, а только шириной проблемы с объединенным доменом. Две нагрузки на 2c и один магазин на 2c - это только половина пропускной способности блоков загрузки и хранения.

Обратите внимание, что режимы адресации с двумя регистрами can't micro-fuse on Intel SnB-family. Это не проблема для чистых нагрузок, потому что они равны 1 мкп даже без микро-слияния.

Анализ идентичен для векторного цикла. (vpaddd имеет латентность 1c на Skylake и почти каждый другой процессор. Таблица не перечисляет ничего в столбце задержки для padd с операндом памяти, так как время ожидания нагрузки не зависит от задержки добавления. добавляет один цикл в DEP цепи с участием регистра SRC/Dest, до тех пор, как адрес нагрузки знаю достаточно далеко впереди времени.)

---

магазина и латентность нагрузки чисел Agner противотуманными являются своего рода поддельным тоже. Он произвольно делит общую задержку в обратном направлении нагрузки (с сохранением-хранением) на число латентности для загрузки и хранения. IDK, почему он не перечислял задержку загрузки, измеренную с помощью теста на сканирование указателя (например, повторный mov (%rsi), %rsi). Это свидетельствует о том, что процессоры Intel SnB-семейства имеют 4 байта задержки загрузки.

Я хотел послать ему записку об этом, но не добрался до него.

---

Вы должны быть видим AVX2 убыстрение 32/4, т.е. 8х. Размер вашей проблемы составляет только 4096B, что достаточно мало для трех массивов такого размера, чтобы вставить в кеш L1. (РЕДАКТ: вопрос вводит в заблуждение: показан цикл, представляющий собой внутренний цикл вложенного цикла. См. Комментарии: по-видимому, даже с 4k массивами (не 4M), OP все еще только видел 3x ускорение (против 1.5x с 4M массивами), поэтому в версии AVX есть какое-то узкое место.)

Все 3 массива выровнены, так что это не переход к кеш-линии в операнде памяти , который не требует выравнивания (%r8).

Моя другая теория на этом тоже не кажется очень вероятной, но ваши адреса массива смещены друг от друга точно в 4096B? Из Agner противотуманными в microarch PDF:

Это не возможно читать и писать одновременно с адресами , которые разнесены на кратное 4 кбайт

пример показывает магазин затем загрузить, хотя, так IDK, если это действительно объясняется. Даже если аппаратное обеспечение для хранения памяти считает, что загрузка и хранение могут быть на одном и том же адресе, я не уверен, почему это остановит код для поддержки как можно большего количества операций с памятью или почему это повлияет на код AVX2 хуже, чем скалярный код ,

Стоит попытаться компенсировать ваши массивы друг от друга дополнительными 128B или 256B или еще чем-то.

Answer 2

Следующее ограничение ограничивает выполнение двух вариантов реализации. Во-первых, кроме счетчика циклов, не существует цепочки зависимостей, связанных с циклом, поэтому операции с различными итерациями цикла могут выполняться сразу, и это означает, что латентность не является основным узким местом, как латентность является важным фактором в HPC. Так как латентности равны, пропускная способность исполнительных блоков более эффективна для обеих реализаций. IACA демонстрирует узкое место пропускной способности для скалярной реализации как «Inter-Iteration», что означает, что существует зависимость между последовательными итерациями цикла и векторизации, что помогает ускорить выполнение кода. Кроме того, vpaddd в векторизованном режиме может быть выдан на портах 5,1, но add использует порты выполнения 1,5,6, когда порт 0 занят в первом цикле. Во-вторых, пропускная способность интерфейсного плавкого домена может влиять на производительность, но в этом алгоритме согласно результатам IACA для обеих реализаций 7 uops для каждой требуемой итерации, а микроархитектура HSW/SKL может выдавать до 4 плавленых- домен uops за такт, поэтому ему требуется 2 цикла на итерацию внутреннего цикла, и это ограничение нарушает реализацию AVX2 больше, чем скалярная реализация. В-третьих, зависимость данных от алгоритма вызывает много промахов в кэше. Уменьшая размер матриц, которые должны быть вписаны в L1D (кеш данных первого уровня), становится фактором 5 (, как бы я не тестировал много времени, чтобы получить 5, но тестирование IDK снова ускорилось - 7,3).