Как мне достичь теоретического максимума 4 FLOP за цикл?

Question

Как мне достичь теоретического максимума 4 FLOP за цикл?

509

Как теоретическая пиковая производительность четырех операций с плавающей запятой (двойная точность) за цикл будет достигнута на современном процессоре Intel x86-64?

Насколько я понимаю, для большинства современных процессоров Intel требуется три цикла для SSE add и пять циклов для mul см., например, Таблицы инструкций Agner Fog '). Из-за конвейерной обработки можно получить пропускную способность одного add за цикл, если алгоритм имеет как минимум три независимых суммирования. Так как это верно для упакованных addpd, а также для скалярных версий addsd, а регистры SSE могут содержать два double, пропускная способность может достигать двух флопов за цикл.

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

Однако, я не смог воспроизвести эту производительность с помощью простой программы C/С++. Моя лучшая попытка привела к 2,7 флопам/циклу. Если кто-то может внести вклад в простую программу C/С++ или ассемблера, которая демонстрирует максимальную производительность, которая будет очень признательна.

Моя попытка:

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

double stoptime(void) {
   struct timeval t;
   gettimeofday(&t,NULL);
   return (double) t.tv_sec + t.tv_usec/1000000.0;
}

double addmul(double add, double mul, int ops){
   // Need to initialise differently otherwise compiler might optimise away
   double sum1=0.1, sum2=-0.1, sum3=0.2, sum4=-0.2, sum5=0.0;
   double mul1=1.0, mul2= 1.1, mul3=1.2, mul4= 1.3, mul5=1.4;
   int loops=ops/10;          // We have 10 floating point operations inside the loop
   double expected = 5.0*add*loops + (sum1+sum2+sum3+sum4+sum5)
               + pow(mul,loops)*(mul1+mul2+mul3+mul4+mul5);

   for (int i=0; i<loops; i++) {
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
   }
   return  sum1+sum2+sum3+sum4+sum5+mul1+mul2+mul3+mul4+mul5 - expected;
}

int main(int argc, char** argv) {
   if (argc != 2) {
      printf("usage: %s <num>\n", argv[0]);
      printf("number of operations: <num> millions\n");
      exit(EXIT_FAILURE);
   }
   int n = atoi(argv[1]) * 1000000;
   if (n<=0)
       n=1000;

   double x = M_PI;
   double y = 1.0 + 1e-8;
   double t = stoptime();
   x = addmul(x, y, n);
   t = stoptime() - t;
   printf("addmul:\t %.3f s, %.3f Gflops, res=%f\n", t, (double)n/t/1e9, x);
   return EXIT_SUCCESS;
}

Скомпилирован с

g++ -O2 -march=native addmul.cpp ; ./a.out 1000

выводит следующий результат на Intel Core i5-750, 2.66 GHz.

addmul:  0.270 s, 3.707 Gflops, res=1.326463

То есть, примерно 1,4 флопа за цикл. Глядя на код ассемблера с помощью g++ -S -O2 -march=native -masm=intel addmul.cpp основной цикл кажется вроде оптимальный для меня:

.L4:
inc    eax
mulsd    xmm8, xmm3
mulsd    xmm7, xmm3
mulsd    xmm6, xmm3
mulsd    xmm5, xmm3
mulsd    xmm1, xmm3
addsd    xmm13, xmm2
addsd    xmm12, xmm2
addsd    xmm11, xmm2
addsd    xmm10, xmm2
addsd    xmm9, xmm2
cmp    eax, ebx
jne    .L4

Изменение скалярных версий с упакованными версиями (addpd и mulpd) приведет к удвоению количества флопов без изменения времени выполнения, и поэтому я бы потерял всего 2.8 флопа за цикл. Есть ли простой пример, который достигает четырех флопов за цикл?

Хорошая небольшая программа Mystical; вот мои результаты (бегите всего на несколько секунд):

gcc -O2 -march=nocona: 5.6 Gflops из 10.66 Gflops (2.1 flops/cycle)
cl /O2, openmp удален: 10.1 Gflops из 10.66 Gflops (3.8 flops/cycle)

Все кажется немного сложным, но мои выводы до сих пор:

gcc -O2 изменяет порядок независимых операций с плавающей запятой с цель чередования addpd и mulpd, если это возможно. То же самое относится к gcc-4.6.2 -O2 -march=core2.
gcc -O2 -march=nocona, похоже, сохраняет порядок операций с плавающей запятой, как определено в источник С++.
cl /O2, 64-разрядный компилятор из SDK для Windows 7 делает цикл-разворачивание автоматически и, кажется, пытается организовать операции так что группы из трех addpd чередуются с тремя mulpd (ну, по крайней мере, в моей системе и для моей простой программы).
Мой Core i5 750 (архитектура Наэлема) не нравится чередующийся add и mul и кажется неспособным для параллельной работы обеих операций. Однако, если сгруппировано в 3, оно внезапно работает как магия.
Другие архитектуры (возможно, Sandy Bridge и другие) появляются иметь возможность выполнять добавление /mul параллельно без проблем если они чередуются в коде сборки.
Хотя трудно признать, но в моей системе cl /O2 намного лучше работает на низкоуровневых операциях оптимизации для моей системы и достигает почти максимальной производительности для небольшого примера С++ выше. Я измерял между 1.85-2.01 flops/cycle (использовали часы() в Windows, что не так точно. Думаю, вам нужно использовать лучший таймер - спасибо Mackie Messer).
Лучшее, что мне удалось с помощью gcc, - это ручное разворачивание и упорядочение дополнения и умножения в группах по три. С g++ -O2 -march=nocona addmul_unroll.cpp Я получаю в лучшем случае 0.207s, 4.825 Gflops, что соответствует 1.8 flops/cycle которым я доволен сейчас.

В коде С++ я заменил цикл for на

   for (int i=0; i<loops/3; i++) {
       mul1*=mul; mul2*=mul; mul3*=mul;
       sum1+=add; sum2+=add; sum3+=add;
       mul4*=mul; mul5*=mul; mul1*=mul;
       sum4+=add; sum5+=add; sum1+=add;

       mul2*=mul; mul3*=mul; mul4*=mul;
       sum2+=add; sum3+=add; sum4+=add;
       mul5*=mul; mul1*=mul; mul2*=mul;
       sum5+=add; sum1+=add; sum2+=add;

       mul3*=mul; mul4*=mul; mul5*=mul;
       sum3+=add; sum4+=add; sum5+=add;
   }

И теперь сборка выглядит как

.L4:
mulsd    xmm8, xmm3
mulsd    xmm7, xmm3
mulsd    xmm6, xmm3
addsd    xmm13, xmm2
addsd    xmm12, xmm2
addsd    xmm11, xmm2
mulsd    xmm5, xmm3
mulsd    xmm1, xmm3
mulsd    xmm8, xmm3
addsd    xmm10, xmm2
addsd    xmm9, xmm2
addsd    xmm13, xmm2
...

user1059432 05 дек. 2011, в 18:53

Источник

163

мммммм. Низкоуровневая оптимизация процессора в комплекте с метриками и родным языком ассемблера ... Меня волнуют самые странные вещи.
e.James 05 дек. 2011, в 18:01
12

Полагаться на время настенных часов, вероятно, является частью причины. Предполагая, что вы работаете с такой операционной системой, как Linux, вы можете в любое время отменить процесс. Такого рода внешние события могут повлиять на ваши показатели производительности.
proc-self-maps 05 дек. 2011, в 18:54
0

Какая у вас версия GCC? Если вы используете Mac по умолчанию, вы столкнетесь с проблемами (это старая версия 4.2).
semisight 05 дек. 2011, в 19:03
1

Да, работает под управлением Linux, но в системе нет нагрузки, и повторение этого много раз мало что -funroll-loops (например, диапазоны 4.0-4.2 Гфлопс для скалярной версии, но теперь с -funroll-loops ). Пробовал с gcc версии 4.4.1 и 4.6.2, но вывод asm выглядит нормально?
user1059432 05 дек. 2011, в 19:05
0

Вы пробовали -O3 для gcc, который включает -ftree-vectorize ? Может быть, в сочетании с -funroll-loops хотя я не буду, если это действительно необходимо. В конце концов, сравнение кажется несправедливым, если один из компиляторов выполняет векторизацию / развертывание, в то время как другой делает это не потому, что не может, а потому, что об этом сказано не слишком.
Grizzly 19 янв. 2012, в 13:52
4

@Grizzly -funroll-loops , наверное, стоит попробовать. Но я думаю, что -ftree-vectorize . ОП пытается просто выдержать 1 муль + 1 инструкцию добавления / цикл. Инструкции могут быть скалярными или векторными - это не имеет значения, поскольку задержка и пропускная способность одинаковы. Так что если вы можете поддерживать 2 / цикл со скалярным SSE, то вы можете заменить их векторным SSE, и вы получите 4 флопа / цикл. В своем ответе я поступил именно так из SSE -> AVX. Я заменил все SSE на AVX - те же задержки, те же пропускные способности, 2x флопс.
Mysticial 20 янв. 2012, в 09:26
1

Один из лучших вопросов анонимного пользователя, который я когда-либо видел на SO. С выдающимися комментариями (мы несколько выросли, ожидая этого от Mysticial, но остальное тоже просто замечательные вещи). Отмеченный!
WhozCraig 12 апр. 2013, в 05:49
0

Кто-нибудь пробовал это с компилятором CLANG LLVM?
Vinícius Gobbo A. de Oliveira 16 авг. 2013, в 21:22
0

@ Vinícius: gcc 4.9.2 не выполняет векторизацию автоматически. clang-3.5 также не выполняет авто-векторизацию: ~ 895M циклов на моем i5-2500k, для итераций = 500000. clang-3.8 делает, с большим количеством перемешиваний вне цикла для обработки нечетного числа переменных. Он выполняет итерации = 500000 в ~ 114.01M тактовых циклов. ( -std=gnu11 -march=native -Ofast -ffast-math , поэтому он использовал AVX1.) Обратите внимание, что FPU в Sandybridge не замедляется с ненормированными значениями, но обычно это происходит в старых FPU.
Peter Cordes 23 сен. 2015, в 00:18

Показать ещё 7 комментариев

Теги:

c++

optimization

architecture

c

assembly

4 ответа

26

В архитектуре Intel, которую люди часто забывают, есть точка, порты отправки разделяются между Int и FP/SIMD. Это означает, что вы получите только определенное количество пакетов FP/SIMD до того, как логика цикла создаст пузырьки в потоке с плавающей точкой. Мистик получил больше провалов из своего кода, потому что он использовал более длительные шаги в своей развернутой петле.

Если вы посмотрите на архитектуру Nehalem/Sandy Bridge здесь http://www.realworldtech.com/page.cfm?ArticleID=RWT091810191937&p=6 это совершенно ясно, что происходит.

В отличие от этого, должно быть проще достичь максимальной производительности на AMD (Bulldozer), поскольку каналы INT и FP/SIMD имеют отдельные порты проблем с собственным планировщиком.

Это теоретически, поскольку я не тестирую ни один из этих процессоров.

Patrick Schlüter 06 дек. 2011, в 16:45

2

Существует только три инструкции для заголовка цикла: inc , cmp и jl . Все они могут идти в порт № 5 и не мешать векторизованному fadd или fmul . Я бы предпочел, чтобы декодер (иногда) мешал. Требуется выдержать от двух до трех инструкций за цикл. Я не помню точных ограничений, но в игру вступают длина инструкции, префиксы и выравнивание.
Mackie Messer 06 дек. 2011, в 16:30
0

cmp и jl конечно, идут в порт 5, в том inc не так уверенно, так как он всегда в группе с двумя другими. Но вы правы, трудно сказать, где находится узкое место, и декодеры также могут быть частью этого.
Patrick Schlüter 06 дек. 2011, в 17:07
3

Я немного поиграл с основным циклом: порядок инструкций имеет значение. Некоторые схемы занимают 13 циклов вместо минимальных 5 циклов. Время взглянуть на счетчики событий производительности, я думаю ...
Mackie Messer 06 дек. 2011, в 18:01

Показать ещё 1 комментарий

14

Филиалы, безусловно, могут препятствовать поддержанию максимальной теоретической производительности. Вы видите разницу, если вы вручную выполняете цикл-разворот? Например, если вы поместили в 5 или 10 раз больше опций для каждой итерации цикла:

for(int i=0; i<loops/5; i++) {
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
      mul1*=mul; mul2*=mul; mul3*=mul; mul4*=mul; mul5*=mul;
      sum1+=add; sum2+=add; sum3+=add; sum4+=add; sum5+=add;
   }

TJD 05 дек. 2011, в 18:28

4

Я могу ошибаться, но я верю, что g ++ с -O2 попытается автоматически размотать цикл (я думаю, что он использует устройство Даффа).
Weaver 05 дек. 2011, в 18:13
6

Да, спасибо, это действительно несколько улучшается. Теперь я получаю около 4,1-4,3 Гфлопс или 1,55 флопс за цикл. И нет, в этом примере -O2 не зациклился.
user1059432 05 дек. 2011, в 18:37
1

Уивер прав насчет раскручивания петли, я полагаю. Так что раскатывать вручную, вероятно, не нужно
jim mcnamara 05 дек. 2011, в 18:40
5

См. Вывод сборки выше, нет признаков разматывания петли.
user1059432 05 дек. 2011, в 18:42
0

Рассматривали ли вы многопоточность (параллелизм бедняков), предполагая, что у вас многоядерный процессор?
jim mcnamara 05 дек. 2011, в 18:42
0

Действительно, многопоточность должна дать мне еще один коэффициент 4 на этом процессоре, но я бы хотел сначала получить максимум от одного ядра.
user1059432 05 дек. 2011, в 18:46
14

Автоматическое развертывание также улучшается в среднем до 4,2 Гфлопс, но требует -funroll-loops которая даже не включена в -O3 . Смотрите g++ -c -Q -O2 --help=optimizers | grep unroll .
user1059432 05 дек. 2011, в 18:55

Показать ещё 5 комментариев

6

Используя Intels icc Version 11.1 на Intel Core 2 Duo с тактовой частотой 2,4 ГГц, я получаю

Macintosh:~ mackie$ icc -O3 -mssse3 -oaddmul addmul.cc && ./addmul 1000
addmul:  0.105 s, 9.525 Gflops, res=0.000000
Macintosh:~ mackie$ icc -v
Version 11.1

Это очень близко к идеалу 9.6 Gflops.

EDIT:

Упс, глядя на код сборки, кажется, что icc не только векторизовал умножение, но и вытащил дополнения из цикла. При форсировании более строгой семантики fp код больше не будет векторизован:

Macintosh:~ mackie$ icc -O3 -mssse3 -oaddmul addmul.cc -fp-model precise && ./addmul 1000
addmul:  0.516 s, 1.938 Gflops, res=1.326463

EDIT2:

В соответствии с запросом:

Macintosh:~ mackie$ clang -O3 -mssse3 -oaddmul addmul.cc && ./addmul 1000
addmul:  0.209 s, 4.786 Gflops, res=1.326463
Macintosh:~ mackie$ clang -v
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

Внутренний цикл кода clang выглядит следующим образом:

        .align  4, 0x90
LBB2_4:                                 ## =>This Inner Loop Header: Depth=1
        addsd   %xmm2, %xmm3
        addsd   %xmm2, %xmm14
        addsd   %xmm2, %xmm5
        addsd   %xmm2, %xmm1
        addsd   %xmm2, %xmm4
        mulsd   %xmm2, %xmm0
        mulsd   %xmm2, %xmm6
        mulsd   %xmm2, %xmm7
        mulsd   %xmm2, %xmm11
        mulsd   %xmm2, %xmm13
        incl    %eax
        cmpl    %r14d, %eax
        jl      LBB2_4

EDIT3:

Наконец, два предложения: во-первых, если вам нравится этот тип бенчмаркинга, подумайте об использовании команды rdtsc istead gettimeofday(2). Он намного точнее и обеспечивает время в циклах, что обычно является тем, что вас интересует. Для gcc и друзей вы можете определить его следующим образом:

#include <stdint.h>

static __inline__ uint64_t rdtsc(void)
{
        uint64_t rval;
        __asm__ volatile ("rdtsc" : "=A" (rval));
        return rval;
}

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

Mackie Messer 05 дек. 2011, в 21:42

2

и как выглядит разборка?
Bahbar 05 дек. 2011, в 20:46
1

Интересно, что это меньше, чем 1 флоп / цикл. Компилятор смешивает addsd и mulsd или они в группах, как в моем выводе сборки? Я также получаю примерно 1 флоп / цикл, когда компилятор смешивает их (что я получаю без -march=native ). Как меняется производительность, если вы добавляете строку add=mul; в начале функции addmul(...) ?
user1059432 06 дек. 2011, в 09:40
1

@ user1059432: инструкции addsd и subsd действительно смешаны в точной версии. Я тоже попробовал clang 3.0, он не смешивает инструкции и очень близок к 2 флопсам / такт на ядре 2 дуэта. Когда я запускаю тот же код на моем ноутбуке Core i5, смешивание кода не имеет значения. Я получаю около 3 флопов / цикл в любом случае.
Mackie Messer 06 дек. 2011, в 13:16
1

@ user1059432: В конце концов, все дело в том, чтобы обмануть компилятор в создании «значимого» кода для синтетического теста. Это сложнее, чем кажется на первый взгляд. (т.е. icc превосходит ваш тест). Если все, что вам нужно, это запустить некоторый код с 4 флопс / цикл, то проще всего написать небольшой цикл сборки. Гораздо меньше головной боли. :-)
Mackie Messer 06 дек. 2011, в 13:30
1

Итак, вы получаете около 2 флоп / цикл с кодом сборки, похожим на тот, который я цитировал выше? Как близко к 2? Я получаю только 1,4, так что это важно. Я не думаю, что вы получаете 3 флопа / цикл на своем ноутбуке, если компилятор не выполняет оптимизацию, как вы видели ранее с icc , можете ли вы дважды проверить сборку?
user1059432 06 дек. 2011, в 14:27
0

@ user1059432: 3 флопа / цикл для ноутбука были неправильными. Я предположил, что он работает на частоте 1,7 ГГц, но, по-видимому, в турбо-режиме он достигает 2,7 ГГц. Таким образом, он работает на чуть менее 2 флопс / цикл тоже. Ну, это так же хорошо, как и без векторизации, верно?
Mackie Messer 06 дек. 2011, в 15:14
0

Еще одна вещь, которую я заметил ... Обратите внимание на дросселирование процессора. Эти тесты с чистыми бездействующими флопами дают много тепла. Я просто попытался запустить свой код на своем ноутбуке, и он заглох и перегрелся ... Я убил его, пока температура не превысила 95C.
Mysticial 06 дек. 2011, в 17:33
1

старый поток, но для записи: rdtsc должен следовать после инструкции сериализации, так как в противном случае он выполняется не по порядку.
markhahn 17 май 2017, в 14:33

Показать ещё 6 комментариев

Ещё вопросы

мммммм. Низкоуровневая оптимизация процессора в комплекте с метриками и родным языком ассемблера ... Меня волнуют самые странные вещи.
Полагаться на время настенных часов, вероятно, является частью причины. Предполагая, что вы работаете с такой операционной системой, как Linux, вы можете в любое время отменить процесс. Такого рода внешние события могут повлиять на ваши показатели производительности.
Какая у вас версия GCC? Если вы используете Mac по умолчанию, вы столкнетесь с проблемами (это старая версия 4.2).
Да, работает под управлением Linux, но в системе нет нагрузки, и повторение этого много раз мало что -funroll-loops (например, диапазоны 4.0-4.2 Гфлопс для скалярной версии, но теперь с -funroll-loops ). Пробовал с gcc версии 4.4.1 и 4.6.2, но вывод asm выглядит нормально?
Вы пробовали -O3 для gcc, который включает -ftree-vectorize ? Может быть, в сочетании с -funroll-loops хотя я не буду, если это действительно необходимо. В конце концов, сравнение кажется несправедливым, если один из компиляторов выполняет векторизацию / развертывание, в то время как другой делает это не потому, что не может, а потому, что об этом сказано не слишком.
@Grizzly -funroll-loops , наверное, стоит попробовать. Но я думаю, что -ftree-vectorize . ОП пытается просто выдержать 1 муль + 1 инструкцию добавления / цикл. Инструкции могут быть скалярными или векторными - это не имеет значения, поскольку задержка и пропускная способность одинаковы. Так что если вы можете поддерживать 2 / цикл со скалярным SSE, то вы можете заменить их векторным SSE, и вы получите 4 флопа / цикл. В своем ответе я поступил именно так из SSE -> AVX. Я заменил все SSE на AVX - те же задержки, те же пропускные способности, 2x флопс.
Один из лучших вопросов анонимного пользователя, который я когда-либо видел на SO. С выдающимися комментариями (мы несколько выросли, ожидая этого от Mysticial, но остальное тоже просто замечательные вещи). Отмеченный!
Кто-нибудь пробовал это с компилятором CLANG LLVM?
@ Vinícius: gcc 4.9.2 не выполняет векторизацию автоматически. clang-3.5 также не выполняет авто-векторизацию: ~ 895M циклов на моем i5-2500k, для итераций = 500000. clang-3.8 делает, с большим количеством перемешиваний вне цикла для обработки нечетного числа переменных. Он выполняет итерации = 500000 в ~ 114.01M тактовых циклов. ( -std=gnu11 -march=native -Ofast -ffast-math , поэтому он использовал AVX1.) Обратите внимание, что FPU в Sandybridge не замедляется с ненормированными значениями, но обычно это происходит в старых FPU.
Существует только три инструкции для заголовка цикла: inc , cmp и jl . Все они могут идти в порт № 5 и не мешать векторизованному fadd или fmul . Я бы предпочел, чтобы декодер (иногда) мешал. Требуется выдержать от двух до трех инструкций за цикл. Я не помню точных ограничений, но в игру вступают длина инструкции, префиксы и выравнивание.
cmp и jl конечно, идут в порт 5, в том inc не так уверенно, так как он всегда в группе с двумя другими. Но вы правы, трудно сказать, где находится узкое место, и декодеры также могут быть частью этого.
Я немного поиграл с основным циклом: порядок инструкций имеет значение. Некоторые схемы занимают 13 циклов вместо минимальных 5 циклов. Время взглянуть на счетчики событий производительности, я думаю ...
Я могу ошибаться, но я верю, что g ++ с -O2 попытается автоматически размотать цикл (я думаю, что он использует устройство Даффа).
Да, спасибо, это действительно несколько улучшается. Теперь я получаю около 4,1-4,3 Гфлопс или 1,55 флопс за цикл. И нет, в этом примере -O2 не зациклился.
Уивер прав насчет раскручивания петли, я полагаю. Так что раскатывать вручную, вероятно, не нужно
См. Вывод сборки выше, нет признаков разматывания петли.
Рассматривали ли вы многопоточность (параллелизм бедняков), предполагая, что у вас многоядерный процессор?
Действительно, многопоточность должна дать мне еще один коэффициент 4 на этом процессоре, но я бы хотел сначала получить максимум от одного ядра.
Автоматическое развертывание также улучшается в среднем до 4,2 Гфлопс, но требует -funroll-loops которая даже не включена в -O3 . Смотрите g++ -c -Q -O2 --help=optimizers | grep unroll .
Интересно, что это меньше, чем 1 флоп / цикл. Компилятор смешивает addsd и mulsd или они в группах, как в моем выводе сборки? Я также получаю примерно 1 флоп / цикл, когда компилятор смешивает их (что я получаю без -march=native ). Как меняется производительность, если вы добавляете строку add=mul; в начале функции addmul(...) ?
@ user1059432: инструкции addsd и subsd действительно смешаны в точной версии. Я тоже попробовал clang 3.0, он не смешивает инструкции и очень близок к 2 флопсам / такт на ядре 2 дуэта. Когда я запускаю тот же код на моем ноутбуке Core i5, смешивание кода не имеет значения. Я получаю около 3 флопов / цикл в любом случае.
@ user1059432: В конце концов, все дело в том, чтобы обмануть компилятор в создании «значимого» кода для синтетического теста. Это сложнее, чем кажется на первый взгляд. (т.е. icc превосходит ваш тест). Если все, что вам нужно, это запустить некоторый код с 4 флопс / цикл, то проще всего написать небольшой цикл сборки. Гораздо меньше головной боли. :-)
Итак, вы получаете около 2 флоп / цикл с кодом сборки, похожим на тот, который я цитировал выше? Как близко к 2? Я получаю только 1,4, так что это важно. Я не думаю, что вы получаете 3 флопа / цикл на своем ноутбуке, если компилятор не выполняет оптимизацию, как вы видели ранее с icc , можете ли вы дважды проверить сборку?
@ user1059432: 3 флопа / цикл для ноутбука были неправильными. Я предположил, что он работает на частоте 1,7 ГГц, но, по-видимому, в турбо-режиме он достигает 2,7 ГГц. Таким образом, он работает на чуть менее 2 флопс / цикл тоже. Ну, это так же хорошо, как и без векторизации, верно?
Еще одна вещь, которую я заметил ... Обратите внимание на дросселирование процессора. Эти тесты с чистыми бездействующими флопами дают много тепла. Я просто попытался запустить свой код на своем ноутбуке, и он заглох и перегрелся ... Я убил его, пока температура не превысила 95C.
старый поток, но для записи: rdtsc должен следовать после инструкции сериализации, так как в противном случае он выполняется не по порядку.

Mysticial · Accepted Answer · 2011-12-05T22-13-00.000Z

Я делал эту точную задачу раньше. Но это было главным образом для измерения энергопотребления и температуры процессора. Следующий код (который довольно длинный) приближается к оптимальному на моем Core i7 2600K.

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

Полный проект можно найти на моем GitHub: https://github.com/Mysticial/Flops

Внимание:

Если вы решили скомпилировать и запустить это, обратите внимание на температуру процессора.
Убедитесь, что вы не перегреваете его. И убедитесь, что дросселирование ЦП не влияет на ваши результаты!

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

Примечания:

Этот код оптимизирован для x64. x86 не имеет достаточного количества регистров для компиляции.
Этот код был хорошо протестирован на Visual Studio 2010/2012 и GCC 4.6.
ICC 11 (Intel Compiler 11) неожиданно имеет проблемы с его компиляцией.
Это для процессоров pre-FMA. Чтобы достичь пиковых FLOPS на процессорах Intel Haswell и AMD Bulldozer (и позже), потребуются инструкции FMA (Fused Multiply Add). Это выходит за рамки этого теста.

#include <emmintrin.h>
#include <omp.h>
#include <iostream>
using namespace std;

typedef unsigned long long uint64;

double test_dp_mac_SSE(double x,double y,uint64 iterations){
    register __m128d r0,r1,r2,r3,r4,r5,r6,r7,r8,r9,rA,rB,rC,rD,rE,rF;

    //  Generate starting data.
    r0 = _mm_set1_pd(x);
    r1 = _mm_set1_pd(y);

    r8 = _mm_set1_pd(-0.0);

    r2 = _mm_xor_pd(r0,r8);
    r3 = _mm_or_pd(r0,r8);
    r4 = _mm_andnot_pd(r8,r0);
    r5 = _mm_mul_pd(r1,_mm_set1_pd(0.37796447300922722721));
    r6 = _mm_mul_pd(r1,_mm_set1_pd(0.24253562503633297352));
    r7 = _mm_mul_pd(r1,_mm_set1_pd(4.1231056256176605498));
    r8 = _mm_add_pd(r0,_mm_set1_pd(0.37796447300922722721));
    r9 = _mm_add_pd(r1,_mm_set1_pd(0.24253562503633297352));
    rA = _mm_sub_pd(r0,_mm_set1_pd(4.1231056256176605498));
    rB = _mm_sub_pd(r1,_mm_set1_pd(4.1231056256176605498));

    rC = _mm_set1_pd(1.4142135623730950488);
    rD = _mm_set1_pd(1.7320508075688772935);
    rE = _mm_set1_pd(0.57735026918962576451);
    rF = _mm_set1_pd(0.70710678118654752440);

    uint64 iMASK = 0x800fffffffffffffull;
    __m128d MASK = _mm_set1_pd(*(double*)&iMASK);
    __m128d vONE = _mm_set1_pd(1.0);

    uint64 c = 0;
    while (c < iterations){
        size_t i = 0;
        while (i < 1000){
            //  Here the meat - the part that really matters.

            r0 = _mm_mul_pd(r0,rC);
            r1 = _mm_add_pd(r1,rD);
            r2 = _mm_mul_pd(r2,rE);
            r3 = _mm_sub_pd(r3,rF);
            r4 = _mm_mul_pd(r4,rC);
            r5 = _mm_add_pd(r5,rD);
            r6 = _mm_mul_pd(r6,rE);
            r7 = _mm_sub_pd(r7,rF);
            r8 = _mm_mul_pd(r8,rC);
            r9 = _mm_add_pd(r9,rD);
            rA = _mm_mul_pd(rA,rE);
            rB = _mm_sub_pd(rB,rF);

            r0 = _mm_add_pd(r0,rF);
            r1 = _mm_mul_pd(r1,rE);
            r2 = _mm_sub_pd(r2,rD);
            r3 = _mm_mul_pd(r3,rC);
            r4 = _mm_add_pd(r4,rF);
            r5 = _mm_mul_pd(r5,rE);
            r6 = _mm_sub_pd(r6,rD);
            r7 = _mm_mul_pd(r7,rC);
            r8 = _mm_add_pd(r8,rF);
            r9 = _mm_mul_pd(r9,rE);
            rA = _mm_sub_pd(rA,rD);
            rB = _mm_mul_pd(rB,rC);

            r0 = _mm_mul_pd(r0,rC);
            r1 = _mm_add_pd(r1,rD);
            r2 = _mm_mul_pd(r2,rE);
            r3 = _mm_sub_pd(r3,rF);
            r4 = _mm_mul_pd(r4,rC);
            r5 = _mm_add_pd(r5,rD);
            r6 = _mm_mul_pd(r6,rE);
            r7 = _mm_sub_pd(r7,rF);
            r8 = _mm_mul_pd(r8,rC);
            r9 = _mm_add_pd(r9,rD);
            rA = _mm_mul_pd(rA,rE);
            rB = _mm_sub_pd(rB,rF);

            r0 = _mm_add_pd(r0,rF);
            r1 = _mm_mul_pd(r1,rE);
            r2 = _mm_sub_pd(r2,rD);
            r3 = _mm_mul_pd(r3,rC);
            r4 = _mm_add_pd(r4,rF);
            r5 = _mm_mul_pd(r5,rE);
            r6 = _mm_sub_pd(r6,rD);
            r7 = _mm_mul_pd(r7,rC);
            r8 = _mm_add_pd(r8,rF);
            r9 = _mm_mul_pd(r9,rE);
            rA = _mm_sub_pd(rA,rD);
            rB = _mm_mul_pd(rB,rC);

            i++;
        }

        //  Need to renormalize to prevent denormal/overflow.
        r0 = _mm_and_pd(r0,MASK);
        r1 = _mm_and_pd(r1,MASK);
        r2 = _mm_and_pd(r2,MASK);
        r3 = _mm_and_pd(r3,MASK);
        r4 = _mm_and_pd(r4,MASK);
        r5 = _mm_and_pd(r5,MASK);
        r6 = _mm_and_pd(r6,MASK);
        r7 = _mm_and_pd(r7,MASK);
        r8 = _mm_and_pd(r8,MASK);
        r9 = _mm_and_pd(r9,MASK);
        rA = _mm_and_pd(rA,MASK);
        rB = _mm_and_pd(rB,MASK);
        r0 = _mm_or_pd(r0,vONE);
        r1 = _mm_or_pd(r1,vONE);
        r2 = _mm_or_pd(r2,vONE);
        r3 = _mm_or_pd(r3,vONE);
        r4 = _mm_or_pd(r4,vONE);
        r5 = _mm_or_pd(r5,vONE);
        r6 = _mm_or_pd(r6,vONE);
        r7 = _mm_or_pd(r7,vONE);
        r8 = _mm_or_pd(r8,vONE);
        r9 = _mm_or_pd(r9,vONE);
        rA = _mm_or_pd(rA,vONE);
        rB = _mm_or_pd(rB,vONE);

        c++;
    }

    r0 = _mm_add_pd(r0,r1);
    r2 = _mm_add_pd(r2,r3);
    r4 = _mm_add_pd(r4,r5);
    r6 = _mm_add_pd(r6,r7);
    r8 = _mm_add_pd(r8,r9);
    rA = _mm_add_pd(rA,rB);

    r0 = _mm_add_pd(r0,r2);
    r4 = _mm_add_pd(r4,r6);
    r8 = _mm_add_pd(r8,rA);

    r0 = _mm_add_pd(r0,r4);
    r0 = _mm_add_pd(r0,r8);


    //  Prevent Dead Code Elimination
    double out = 0;
    __m128d temp = r0;
    out += ((double*)&temp)[0];
    out += ((double*)&temp)[1];

    return out;
}

void test_dp_mac_SSE(int tds,uint64 iterations){

    double *sum = (double*)malloc(tds * sizeof(double));
    double start = omp_get_wtime();

#pragma omp parallel num_threads(tds)
    {
        double ret = test_dp_mac_SSE(1.1,2.1,iterations);
        sum[omp_get_thread_num()] = ret;
    }

    double secs = omp_get_wtime() - start;
    uint64 ops = 48 * 1000 * iterations * tds * 2;
    cout << "Seconds = " << secs << endl;
    cout << "FP Ops  = " << ops << endl;
    cout << "FLOPs   = " << ops / secs << endl;

    double out = 0;
    int c = 0;
    while (c < tds){
        out += sum[c++];
    }

    cout << "sum = " << out << endl;
    cout << endl;

    free(sum);
}

int main(){
    //  (threads, iterations)
    test_dp_mac_SSE(8,10000000);

    system("pause");
}

Вывод (1 поток, итерации 10000000) - Скомпилирован с Visual Studio 2010 SP1 - x64 Release:

Seconds = 55.5104
FP Ops  = 960000000000
FLOPs   = 1.7294e+010
sum = 2.22652

Аппарат Core i7 2600K @4.4 ГГц. Теоретический пик SSE составляет 4 флопа * 4.4 ГГц = 17.6 GFlops. Этот код достигает 17.3 GFlops - неплохо.

Вывод (8 потоков, итераций 10000000) - Скомпилирован с Visual Studio 2010 SP1 - x64 Release:

Seconds = 117.202
FP Ops  = 7680000000000
FLOPs   = 6.55279e+010
sum = 17.8122

Теоретический пик SSE составляет 4 флопа * 4 ядра * 4.4 ГГц = 70.4 GFlops. Фактический 65,5 GFlops.

Давайте сделаем еще один шаг. AVX...

#include <immintrin.h>
#include <omp.h>
#include <iostream>
using namespace std;

typedef unsigned long long uint64;

double test_dp_mac_AVX(double x,double y,uint64 iterations){
    register __m256d r0,r1,r2,r3,r4,r5,r6,r7,r8,r9,rA,rB,rC,rD,rE,rF;

    //  Generate starting data.
    r0 = _mm256_set1_pd(x);
    r1 = _mm256_set1_pd(y);

    r8 = _mm256_set1_pd(-0.0);

    r2 = _mm256_xor_pd(r0,r8);
    r3 = _mm256_or_pd(r0,r8);
    r4 = _mm256_andnot_pd(r8,r0);
    r5 = _mm256_mul_pd(r1,_mm256_set1_pd(0.37796447300922722721));
    r6 = _mm256_mul_pd(r1,_mm256_set1_pd(0.24253562503633297352));
    r7 = _mm256_mul_pd(r1,_mm256_set1_pd(4.1231056256176605498));
    r8 = _mm256_add_pd(r0,_mm256_set1_pd(0.37796447300922722721));
    r9 = _mm256_add_pd(r1,_mm256_set1_pd(0.24253562503633297352));
    rA = _mm256_sub_pd(r0,_mm256_set1_pd(4.1231056256176605498));
    rB = _mm256_sub_pd(r1,_mm256_set1_pd(4.1231056256176605498));

    rC = _mm256_set1_pd(1.4142135623730950488);
    rD = _mm256_set1_pd(1.7320508075688772935);
    rE = _mm256_set1_pd(0.57735026918962576451);
    rF = _mm256_set1_pd(0.70710678118654752440);

    uint64 iMASK = 0x800fffffffffffffull;
    __m256d MASK = _mm256_set1_pd(*(double*)&iMASK);
    __m256d vONE = _mm256_set1_pd(1.0);

    uint64 c = 0;
    while (c < iterations){
        size_t i = 0;
        while (i < 1000){
            //  Here the meat - the part that really matters.

            r0 = _mm256_mul_pd(r0,rC);
            r1 = _mm256_add_pd(r1,rD);
            r2 = _mm256_mul_pd(r2,rE);
            r3 = _mm256_sub_pd(r3,rF);
            r4 = _mm256_mul_pd(r4,rC);
            r5 = _mm256_add_pd(r5,rD);
            r6 = _mm256_mul_pd(r6,rE);
            r7 = _mm256_sub_pd(r7,rF);
            r8 = _mm256_mul_pd(r8,rC);
            r9 = _mm256_add_pd(r9,rD);
            rA = _mm256_mul_pd(rA,rE);
            rB = _mm256_sub_pd(rB,rF);

            r0 = _mm256_add_pd(r0,rF);
            r1 = _mm256_mul_pd(r1,rE);
            r2 = _mm256_sub_pd(r2,rD);
            r3 = _mm256_mul_pd(r3,rC);
            r4 = _mm256_add_pd(r4,rF);
            r5 = _mm256_mul_pd(r5,rE);
            r6 = _mm256_sub_pd(r6,rD);
            r7 = _mm256_mul_pd(r7,rC);
            r8 = _mm256_add_pd(r8,rF);
            r9 = _mm256_mul_pd(r9,rE);
            rA = _mm256_sub_pd(rA,rD);
            rB = _mm256_mul_pd(rB,rC);

            r0 = _mm256_mul_pd(r0,rC);
            r1 = _mm256_add_pd(r1,rD);
            r2 = _mm256_mul_pd(r2,rE);
            r3 = _mm256_sub_pd(r3,rF);
            r4 = _mm256_mul_pd(r4,rC);
            r5 = _mm256_add_pd(r5,rD);
            r6 = _mm256_mul_pd(r6,rE);
            r7 = _mm256_sub_pd(r7,rF);
            r8 = _mm256_mul_pd(r8,rC);
            r9 = _mm256_add_pd(r9,rD);
            rA = _mm256_mul_pd(rA,rE);
            rB = _mm256_sub_pd(rB,rF);

            r0 = _mm256_add_pd(r0,rF);
            r1 = _mm256_mul_pd(r1,rE);
            r2 = _mm256_sub_pd(r2,rD);
            r3 = _mm256_mul_pd(r3,rC);
            r4 = _mm256_add_pd(r4,rF);
            r5 = _mm256_mul_pd(r5,rE);
            r6 = _mm256_sub_pd(r6,rD);
            r7 = _mm256_mul_pd(r7,rC);
            r8 = _mm256_add_pd(r8,rF);
            r9 = _mm256_mul_pd(r9,rE);
            rA = _mm256_sub_pd(rA,rD);
            rB = _mm256_mul_pd(rB,rC);

            i++;
        }

        //  Need to renormalize to prevent denormal/overflow.
        r0 = _mm256_and_pd(r0,MASK);
        r1 = _mm256_and_pd(r1,MASK);
        r2 = _mm256_and_pd(r2,MASK);
        r3 = _mm256_and_pd(r3,MASK);
        r4 = _mm256_and_pd(r4,MASK);
        r5 = _mm256_and_pd(r5,MASK);
        r6 = _mm256_and_pd(r6,MASK);
        r7 = _mm256_and_pd(r7,MASK);
        r8 = _mm256_and_pd(r8,MASK);
        r9 = _mm256_and_pd(r9,MASK);
        rA = _mm256_and_pd(rA,MASK);
        rB = _mm256_and_pd(rB,MASK);
        r0 = _mm256_or_pd(r0,vONE);
        r1 = _mm256_or_pd(r1,vONE);
        r2 = _mm256_or_pd(r2,vONE);
        r3 = _mm256_or_pd(r3,vONE);
        r4 = _mm256_or_pd(r4,vONE);
        r5 = _mm256_or_pd(r5,vONE);
        r6 = _mm256_or_pd(r6,vONE);
        r7 = _mm256_or_pd(r7,vONE);
        r8 = _mm256_or_pd(r8,vONE);
        r9 = _mm256_or_pd(r9,vONE);
        rA = _mm256_or_pd(rA,vONE);
        rB = _mm256_or_pd(rB,vONE);

        c++;
    }

    r0 = _mm256_add_pd(r0,r1);
    r2 = _mm256_add_pd(r2,r3);
    r4 = _mm256_add_pd(r4,r5);
    r6 = _mm256_add_pd(r6,r7);
    r8 = _mm256_add_pd(r8,r9);
    rA = _mm256_add_pd(rA,rB);

    r0 = _mm256_add_pd(r0,r2);
    r4 = _mm256_add_pd(r4,r6);
    r8 = _mm256_add_pd(r8,rA);

    r0 = _mm256_add_pd(r0,r4);
    r0 = _mm256_add_pd(r0,r8);

    //  Prevent Dead Code Elimination
    double out = 0;
    __m256d temp = r0;
    out += ((double*)&temp)[0];
    out += ((double*)&temp)[1];
    out += ((double*)&temp)[2];
    out += ((double*)&temp)[3];

    return out;
}

void test_dp_mac_AVX(int tds,uint64 iterations){

    double *sum = (double*)malloc(tds * sizeof(double));
    double start = omp_get_wtime();

#pragma omp parallel num_threads(tds)
    {
        double ret = test_dp_mac_AVX(1.1,2.1,iterations);
        sum[omp_get_thread_num()] = ret;
    }

    double secs = omp_get_wtime() - start;
    uint64 ops = 48 * 1000 * iterations * tds * 4;
    cout << "Seconds = " << secs << endl;
    cout << "FP Ops  = " << ops << endl;
    cout << "FLOPs   = " << ops / secs << endl;

    double out = 0;
    int c = 0;
    while (c < tds){
        out += sum[c++];
    }

    cout << "sum = " << out << endl;
    cout << endl;

    free(sum);
}

int main(){
    //  (threads, iterations)
    test_dp_mac_AVX(8,10000000);

    system("pause");
}

Вывод (1 поток, итерации 10000000) - Скомпилирован с Visual Studio 2010 SP1 - x64 Release:

Seconds = 57.4679
FP Ops  = 1920000000000
FLOPs   = 3.34099e+010
sum = 4.45305

Теоретический пик AVX - 8 флопов * 4.4 ГГц = 35.2 GFlops. Фактически 33.4 GFlops.

Вывод (8 потоков, итераций 10000000) - Скомпилирован с Visual Studio 2010 SP1 - x64 Release:

Seconds = 111.119
FP Ops  = 15360000000000
FLOPs   = 1.3823e+011
sum = 35.6244

Теоретический пик AVX - 8 флопов * 4 ядра * 4.4 ГГц = 140.8 GFlops. Фактический 138.2 GFlops.

Теперь для некоторых объяснений:

Критическая часть производительности - это, по-видимому, 48 инструкций внутри внутреннего цикла. Вы заметите, что он разбит на 4 блока по 12 инструкций каждый. Каждый из этих 12 блоков инструкций полностью независим друг от друга - и принимает в среднем 6 циклов для выполнения.

Таким образом, существует 12 инструкций и 6 циклов между выпуском. Задержка умножения составляет 5 тактов, поэтому этого достаточно, чтобы избежать латентных ларьков.

Шаг нормализации необходим для того, чтобы данные перегружались/переполнялись. Это необходимо, поскольку код do-nothing будет медленно увеличивать/уменьшать величину данных.

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

Дополнительные результаты:

Intel Core i7 920 @3.5 ГГц
Windows 7 Ultimate x64
Visual Studio 2010 SP1 - выпуск x64

Темы: 1

Seconds = 72.1116
FP Ops  = 960000000000
FLOPs   = 1.33127e+010
sum = 2.22652

Теоретический пик SSE: 4 флопа * 3.5 ГГц = 14.0 GFlops. Фактически 13.3 GFlops.

Темы: 8

Seconds = 149.576
FP Ops  = 7680000000000
FLOPs   = 5.13452e+010
sum = 17.8122

Теоретический пик SSE: 4 флопа * 4 ядра * 3.5 ГГц = 56.0 GFlops. Фактически 51.3 GFlops.

Мое процессорное время попало на 76C при многопоточном запуске! Если вы их используете, убедитесь, что на результаты не влияет дросселирование ЦП.

2 x Intel Xeon X5482 Harpertown @3.2 ГГц
Ubuntu Linux 10 x64
GCC 4.5.2 x64 - (-O2 -msse3 -fopenmp)

Темы: 1

Seconds = 78.3357
FP Ops  = 960000000000
FLOPs   = 1.22549e+10
sum = 2.22652

Теоретический пик SSE: 4 флопа * 3.2 ГГц = 12.8 GFlops. Фактически 12.3 GFlops.

Темы: 8

Seconds = 78.4733
FP Ops  = 7680000000000
FLOPs   = 9.78676e+10
sum = 17.8122

Теоретический пик SSE: 4 флопа * 8 ядер * 3.2 ГГц = 102.4 GFlops. Фактически 97.9 GFlops.

Ваши результаты очень впечатляют. Я скомпилировал ваш код с помощью g ++ на моей старой системе, но не получил столь же хороших результатов: 100 1.814s, 5.292 Gflops, sum=0.448883 итераций, 1.814s, 5.292 Gflops, sum=0.448883 из пиковых 10,68 Gflops или чуть меньше 2,0 флопов за цикл. Кажется, add / mul не выполняется параллельно. Когда я изменяю ваш код и всегда добавляю / rC один и тот же регистр, скажем, rC , он внезапно достигает почти пика: 0.953s, 10.068 Gflops, sum=0 или 3,8 флопс / цикл. Очень странно.
Да, поскольку я не использую встроенную сборку, производительность действительно очень чувствительна к компилятору. Код, который я здесь, был настроен для VC2010. И если я правильно помню, Intel Compiler дает такие же хорошие результаты. Как вы заметили, вам, возможно, придется немного его настроить, чтобы он хорошо компилировался.
На самом деле, вы уверены, что компилируете для x64? Если это x86, он будет выглядеть как сумасшедший, если вы не сделаете то, что сделали - используйте тот же регистр, и пусть аппаратное обеспечение справится с этим с переименованием регистра.
Глядя на ассемблерный код g ++, вы сохраняете порядок инструкций вашего основного внутреннего цикла, т.е. mulpd xmm0, xmm5 , addpd xmm1, xmm4 , mulpd xmm15, xmm3 , subpd xmm14, xmm2 , ..., так что я думаю, что это может быть проблема компилятора, но, возможно, архитектурная разница между моим Nehalem и вашим процессором Sandy Bridge или, может быть, ОС? Вы тестировали свою программу на разных процессорах? И да, я компилирую 64-битный режим и проверил, что сборка в порядке.
Я только что запустил его на своем Core i7 920 @ 3,5 ГГц. Теоретический = 14 GFlops . Фактически: 13,3 GFlops . Все еще под Windows + VS2010. Так что определенно происходит что-то смешное ... К сожалению, в данный момент у меня нет машины с Linux.
Я только что проверил это с Intel Compiler на Windows. Похоже, что он также имеет проблемы с перекрытием mul и add s. Поскольку он получает только 11,1 GFlops против 14,0 теоретических . Когда я смотрю на сборку, она «толкает» дополнения вниз по циклу, чтобы не было совпадений в начале или в конце ... Поэтому я думаю, что это очень зависит от компилятора. Видимо, я неправильно напомнил, что компилятор Intel дал такие же хорошие результаты - он должен был быть на другом уровне.
Я только добавил некоторые новые результаты на моем сервере. Собранный с GCC 4.5.2, он также дает очень хорошие результаты. Тем не менее, я хочу отметить, что этот тест имеет тенденцию нагревать процессор до предельных уровней. Так что, если вы видите плохие результаты, убедитесь, что это не из-за дросселирования процессора .
Я могу подтвердить ваши результаты в Windows 7, используя cl /O2 (64-битный от Windows SDK), и даже мой пример работает там близко к пику для скалярных операций (1,9 флопс / цикл). Цикл развертывания и переупорядочения компилятора, но это, возможно, не является причиной, по которой нужно больше разбираться в этом. Дросселирование не проблема, я хорошо отношусь к своему процессору и держу итерации на 100k. :)
Вы объявляете r0 как «регистр», но затем берете адрес с помощью & r0. Кланг, естественно, выдает ошибку.
@ jørgensen Вы можете избавиться от декларации register или изменить &r0 . Я не думаю, что какой-либо современный компилятор обращает на это внимание больше. Я помещаю это больше как вещь читабельности. Но в любом случае я проверял это только на MSVC и g ++.
В этом ответе следует указать, что конструкция процессоров AMD FX и APU серии A предусматривает только два 128-битных SSE или один 256-битный конвейер AVX на каждые два ядра ЦП .
@greyfade Мало того, но для достижения максимума на этом, этот эталон должен быть обновлен, чтобы использовать инструкции FMA. Как бы мне ни хотелось поиграть с этим, на самом деле у меня нет доступа к машине с архитектурой AMD Bulldozer.
В любом случае, этот вопрос, кажется, привлекает какое-то необычное внимание сегодня, и в последний раз, когда я касался его, это было более года назад. Я посмотрю, смогу ли я обновить код, чтобы сделать его более удобным для копирования и вставки.
@Mysticial: Сегодня он появился в субреддите r / coding .
+1. Потрясающие. Некоторые вопросы, хотя: процессор тает или компьютер взлетает при запуске? :)
@haylem Либо тает, либо взлетает. Никогда оба. Если будет достаточно охлаждения, он получит эфирное время. В противном случае он просто тает. :)
@ Mystic: у вас есть подобный код для Haswell? У меня есть i7-4700MQ, который я бы хотел растопить!
@ Mehrdad Пока нет. Но у меня есть оборудование для этого. Мне просто нужно найти время, чтобы сесть и на самом деле сделать это. :)
@ Мистик: Хаха, хорошо. Если (э, когда) вы это сделаете, пожалуйста, дайте мне знать! Спасибо! лол
@Mehrdad FMA3 добавлен. Но это не так жарко, как я ожидал. Стресс-тест моей Пи-программы, кажется, работает жарче. Я подозреваю, что нехватка кеша и доступа к памяти "вредит" этому тесту в "отделе отопления". :(
@ Мистика: Ой, ха-ха, хорошо, спасибо!
Только я не знаю, что этот код делает с моими регистрами процессора?
Насколько важен кэш инструкций при написании такого кода с максимальной эффективностью? Мне всегда интересно с такими агрессивно развернутыми примерами, насколько релевантен кеш инструкций. Промах «inter-icache» при выходе из функции кажется тривиальным, учитывая, сколько времени затрачивается на эту функцию, но на каком уровне становится безумным так много раз развертывать промахи внутри-icache в одной и той же функции? Это вообще не проблема?
@Ike Ичак на самом деле довольно большой. Это будет легко соответствовать развернутой петле в этом тесте. Следует признать, что тестировать icache сложно, поскольку, когда код становится настолько большим, вы одновременно начинаете сталкиваться с ограничениями декодера.
@Mysticial Что такое коэффициент умножения 2 в строке 'uint64 ops = 48 * 1000 * повторений * tds * 2;' ?
@TusharSudake Это для SIMD. Каждая из этих инструкций SSE2 выполняет две операции.
@ Мистик Спасибо! Есть ли какой-либо официальный источник, который предполагал бы фактор 2 или 4 (количество операций на инструкцию)? Я старался изо всех сил, но не мог найти один.
@TusharSudake Просто посмотрите инструкцию. Например, если вы используете Google для _mm_mul_pd() он говорит, что он умножает две пары двойных чисел.
using namespace std; плохая практика , никогда не используйте ее.