Очередной программист решил проверить выигрыш от использования новых команд AVX-2 и 256-разрядных регистров. Набросал простой и понятный тест и....
получил двукратное замедление по сравнению с "обычными" командами. Кстати, выигрыш от использования SSE2 тоже не впечатляет.

Несколько лет назад сам я тоже вычислительную процедурку перевел на SSE2 и не увидел НИКАКОГО ускорения. И это был уже не тест, а реальные вычисления.
Попытки объяснить все "промахами кэша" выглядят очень бледно. Разводилово все эти новые возможности.
Вот его результаты:

cycles____________ instructions
187,888,737 ___ 366,382,169___ C original
167,129,257 ___ 282,694,918___ SSE2
390,340,078 ___ 168,337,307___ AVX2

Текст оригинального сообщения:

https://groups.google.com/forum/#!topic/comp.lang.asm.x86/j7wBKVUOmfI

Здравствуйте, кт, Вы писали:

кт>Кстати, выигрыш от использования SSE2 тоже не впечатляет.

void tsp(point cities[], double tourx[], double toury[], int ncities)
{
  int i;
  double *ClosePt=tourx;
  double CloseDist;
  double *p;
  
  // ...
  
  for (i=1; i<ncities; i++) {
    double ThisX = tourx[i-1];
    double ThisY = toury[i-1];
    CloseDist = DBL_MAX;
    for (p=&tourx[ncities];;) {
      double ThisDist;
      asm("movapd %[closeDist], %%xmm4\n"
          "    shufpd $0, %%xmm4, %%xmm4\n"
          "    movapd %[thisx], %%xmm6\n"

Может быть, надо было просто корректно выравнить CloseDist, ThisX и т.д.?
SSE ведь предъявляет определенные требования к выравниванию данных...

Здравствуйте, кт, Вы писали:

кт>Очередной программист решил проверить выигрыш от использования новых команд AVX-2 и 256-разрядных регистров. Набросал простой и понятный тест и....
кт>получил двукратное замедление по сравнению с "обычными" командами. Кстати, выигрыш от использования SSE2 тоже не впечатляет.

кт>Несколько лет назад сам я тоже вычислительную процедурку перевел на SSE2 и не увидел НИКАКОГО ускорения. И это был уже не тест, а реальные вычисления.
кт>Попытки объяснить все "промахами кэша" выглядят очень бледно. Разводилово все эти новые возможности.
кт>Вот его результаты:

кт> cycles____________ instructions
кт>187,888,737 ___ 366,382,169___ C original
кт>167,129,257 ___ 282,694,918___ SSE2
кт>390,340,078 ___ 168,337,307___ AVX2

кт>Текст оригинального сообщения:

кт>https://groups.google.com/forum/#!topic/comp.lang.asm.x86/j7wBKVUOmfI

Очень авторитетный тест

Здравствуйте, okman, Вы писали:

O>Может быть, надо было просто корректно выравнить CloseDist, ThisX и т.д.?
O>SSE ведь предъявляет определенные требования к выравниванию данных...

Если не выровнять данные, будет ошибка доступа, так что все выровнено

Здравствуйте, kov_serg, Вы писали:

_>Очень авторитетный тест

Да, черт с ним с тестом. Но я переводил реальную задачу и от SSE2 ничего не получил. Точнее, скорость не изменилась более чем на 1-2%

Здравствуйте, кт, Вы писали:

кт>Здравствуйте, kov_serg, Вы писали:

_>>Очень авторитетный тест

кт>Да, черт с ним с тестом. Но я переводил реальную задачу и от SSE2 ничего не получил. Точнее, скорость не изменилась более чем на 1-2%

а я переводил реальную задачу и получил прирост производительности в 10% на новых инструкциях. Может вы их просто готовить не умеете ?

Здравствуйте, кт, Вы писали:

У меня реализация ассиметричных шифров на AVX выдаёт в разы большую производительность, чем реализация на "стандартных" инструкциях и регистрах. Во-первых, там есть нюансы их применения, во-вторых, не каждая задача даст прирост. Конкретно на задачах криптухи эти команды дают прирост значительный.

Здравствуйте, mike_rs, Вы писали:

_>а я переводил реальную задачу и получил прирост производительности в 10% на новых инструкциях. Может вы их просто готовить не умеете ?

ну поделитесь своим алгоритмом, например, умножения нормированного вектора на матрицу. Вот мой вариант:


;---- ДОСТАЕМ МОДУЛЬ ОЧЕРЕДНОГО ВЕКТОРА ----

MOVLPD XMM0,[ECX+EDI*8] ;ЗАГРУЗИЛИ МОДУЛЬ

;---- ПОЛУЧЕНИЕ 3 СОСТАВЛЯЮЩИХ ДЛЯ УМНОЖЕНИЯ НА МАТРИЦУ ----

SHUFPD XMM0,XMM0,0 ;РАЗМНОЖИЛИ МОДУЛЬ В XMM0
MOVLPD XMM2,[ESI]+8*0 ;БЕРЕМ СОСТАВЛЯЮЩУЮ ПО X
MOVHPD XMM2,[ESI]+8*2 ;БЕРЕМ СОСТАВЛЯЮЩУЮ ПО Z
MOVUPD XMM1,XMM0 ;РАЗМНОЖИЛИ
MULPD XMM2,XMM0 ;ПОЛУЧИЛИ 1-3 (УМНОЖАЯ НА X И Z)

;---- ФОРМИРУЕМ КОНСТАНТЫ УМНОЖЕНИЯ НА МАТРИЦУ 1-2 3-1 2-3 ----

MOVSD XMM0,XMM2 ;ПОЛУЧИЛИ 1-2
SHUFPD XMM2,XMM2,1 ;ПОЛУЧИЛИ 3-1
MOVSD XMM1,XMM2 ;ПОЛУЧИЛИ 3-2
MOVSD XMM1,XMM2 ;ПОЛУЧИЛИ 3-2
MOV ESI,OFFSET __IR ;АДРЕС МАТРИЦЫ
SHUFPD XMM1,XMM1,1 ;ПОЛУЧИЛИ 2-3

;------------------ УМНОЖЕНИЕ ВЕКТОРА НА МАТРИЦУ ПЕРЕХОДА ------------------

MOVDQU XMM3,[ESI]+8*0 ;XMM3 1-2
MOVDQU XMM4,[ESI]+8*2 ;XMM4 3-1

MULPD XMM3,XMM0 ;САМО УМНОЖЕНИЕ (X,Y)
MULPD XMM4,XMM2 ;САМО УМНОЖЕНИЕ (Z X)

MOVDQU XMM5,[ESI]+8*4 ;XMM5 2-3
MOVDQU XMM6,[ESI]+8*6 ;XMM6 1-2

MULPD XMM5,XMM1 ;САМО УМНОЖЕНИЕ (Y Z)
MOVLPD XMM7,[ESI]+8*8 ;XMM7 3-X
MULPD XMM6,XMM0 ;САМО УМНОЖЕНИЕ (X Y)

MULSD XMM7,XMM2 ;УМНОЖЕНИЕ ПОСЛЕДНЕГО ЭЛЕМЕНТА (Z)

Здравствуйте, кт, Вы писали:

кт>Очередной программист решил проверить выигрыш от использования новых команд AVX-2 и 256-разрядных регистров. Набросал простой и понятный тест и....
кт>получил двукратное замедление по сравнению с "обычными" командами. Кстати, выигрыш от использования SSE2 тоже не впечатляет.

Нужно учитывать работу турбо-буста, также видимо на переключение на AVX время требуется. Т.е. для небольшого количеста комманд, действительно смысла нет. Когда же данных много, прибавка в разы. То же перемножение больших матриц — linpack. Первые четыехядерные core quad без SSE2 — 30 Гфлопс (3.4Ггц), i7-6400t (3,6Ггц) — 200Гфлопс.

Здравствуйте, _ilya_, Вы писали:


__>Нужно учитывать работу турбо-буста, также видимо на переключение на AVX время требуется. Т.е. для небольшого количеста комманд, действительно смысла нет.

Согласен. Но каждому кажется — ну вот же 4 числа за раз. Где мое 4-х кратное ускорение?

Здравствуйте, кт, Вы писали:

кт>Попытки объяснить все "промахами кэша" выглядят очень бледно. Разводилово все эти новые возможности.
кт>Вот его результаты:

Не "промахами кэша", Вы или слишком рано читали дискуссию, или недочитали.
Добавление vzeroupper (соответствующими опциями компиляции) исправило ситуацию.

Тут ещё надо учитывать особенности версий компилятора. Например, у меня было, что gcc 4.8 при -march=native неправильно компилировал, включая AVX, но без адекватной зачистки. Аналогичное с 4.9 показало втыкание всяких vxorps регистра с собой же (такая же зачистка, но для одного регистра) перед заливкой данных, и это сразу ускорило весь алгоритм в 2 раза.

кт>Несколько лет назад сам я тоже вычислительную процедурку перевел на SSE2 и не увидел НИКАКОГО ускорения. И это был уже не тест, а реальные вычисления.

Без точных данных, что происходило, это утверждение не имеет ценности.

Здравствуйте, кт, Вы писали:

O>>Может быть, надо было просто корректно выравнить CloseDist, ThisX и т.д.?
O>>SSE ведь предъявляет определенные требования к выравниванию данных...

кт>Если не выровнять данные, будет ошибка доступа, так что все выровнено

На x86 — нет, не будет. Точнее, не всегда. Если читать данные, например, через movaps, то будет, если movups — нет. Но на практике за счёт кэша L1 разница в скорости становится ничтожной для большинства обычных применений.