Замена 32-разрядного счетчика циклов на 64-разрядный вводит сумасшедшие отклонения производительности

Я закодировал эквивалентную программу для экспериментов, и я могу подтвердить это странное поведение. Что еще, gcc считает, что 64-битное целое число (которое, вероятно, должно быть size_t в любом случае...) должно быть лучше, поскольку использование uint_fast32_t заставляет gcc использовать 64-разрядный uint.

Я немного сработал с сборкой:
Просто возьмите 32-битную версию, замените все 32-разрядные инструкции/регистры на 64-битную версию во внутреннем цикле программы popcount. Наблюдение: код так же быстро, как 32-битная версия!

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

Затем я скопировал код внутреннего цикла из 32-разрядной версии программы, взломал ее до 64 бит, переиграв регистры, чтобы заменить ее внутренним циклом 64-битной версии. Этот код также работает так же быстро, как 32-разрядная версия.

Я пришел к выводу, что это плохое планирование команд компилятором, а не фактическое преимущество скорости/задержки 32-битных инструкций.

(Предостережение: я взломал сборку, мог что-то сломать, не заметив. так думай.)

Это не ответ, но его трудно прочитать, если я поставлю результаты в комментарии.

Я получаю эти результаты с помощью Mac Pro (Westmere 6-Cores Xeon 3.33 GHz). Я скомпилировал его с clang -O3 -msse4 -lstdc++ a.cpp -o a (-O2 получить тот же результат).

clang с uint64_t size=atol(argv[1])<<20;

unsigned    41950110000 0.811198 sec    12.9263 GB/s
uint64_t    41950110000 0.622884 sec    16.8342 GB/s

clang с uint64_t size=1<<20;

unsigned    41950110000 0.623406 sec    16.8201 GB/s
uint64_t    41950110000 0.623685 sec    16.8126 GB/s

Я также попытался:

• Отмените порядок тестирования, результат будет таким же, чтобы исключить фактор кеша.
• Выполните оператор for в обратном порядке: for (uint64_t i=size/8;i>0;i-=4). Это дает тот же результат и доказывает, что компилятор достаточно умен, чтобы не разделить размер на 8 на каждой итерации (как и ожидалось).

Вот мое дикое предположение:

Коэффициент скорости входит в три части:

• кеш кода: uint64_t версия имеет больший размер кода, но это не влияет на мой процессор Xeon. Это замедляет работу 64-разрядной версии.

• Используемые инструкции. Обратите внимание не только на количество циклов, но и на буфер, с 32-битным и 64-разрядным индексом на двух версиях. Доступ к указателю с 64-битным смещением запрашивает выделенный 64-битный регистр и адресацию, в то время как вы можете использовать немедленное для 32-битного смещения. Это может сделать 32-разрядную версию быстрее.

• Инструкции выдаются только в 64-битной компиляции (т.е. предварительной выборке). Это делает 64-бит быстрее.

Три фактора вместе совпадают с наблюдаемыми, казалось бы, противоречивыми результатами.

Я попробовал это с Visual Studio 2013 Express, используя указатель вместо индекса, который немного ускорил процесс. Я подозреваю, что это потому, что адресация смещена + регистр, а не смещение + регистр + (регистр < 3). Код на С++.

   uint64_t* bfrend = buffer+(size/8);
   uint64_t* bfrptr;

// ...

   {
      startP = chrono::system_clock::now();
      count = 0;
      for (unsigned k = 0; k < 10000; k++){
         // Tight unrolled loop with uint64_t
         for (bfrptr = buffer; bfrptr < bfrend;){
            count += __popcnt64(*bfrptr++);
            count += __popcnt64(*bfrptr++);
            count += __popcnt64(*bfrptr++);
            count += __popcnt64(*bfrptr++);
         }
      }
      endP = chrono::system_clock::now();
      duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
      cout << "uint64_t\t"  << count << '\t' << (duration/1.0E9) << " sec \t"
           << (10000.0*size)/(duration) << " GB/s" << endl;
   }

код сборки: r10 = bfrptr, r15 = bfrend, rsi = count, rdi = buffer, r13 = k:

$LL5@main:
        mov     r10, rdi
        cmp     rdi, r15
        jae     SHORT $LN4@main
        npad    4
$LL2@main:
        mov     rax, QWORD PTR [r10+24]
        mov     rcx, QWORD PTR [r10+16]
        mov     r8, QWORD PTR [r10+8]
        mov     r9, QWORD PTR [r10]
        popcnt  rdx, rax
        popcnt  rax, rcx
        add     rdx, rax
        popcnt  rax, r8
        add     r10, 32
        add     rdx, rax
        popcnt  rax, r9
        add     rsi, rax
        add     rsi, rdx
        cmp     r10, r15
        jb      SHORT $LL2@main
$LN4@main:
        dec     r13
        jne     SHORT $LL5@main

Я не могу дать авторитетный ответ, но даю обзор вероятной причины. Эта ссылка довольно ясно показывает, что для инструкций в теле вашего цикла существует соотношение между задержкой и пропускной способностью 3: 1. Он также показывает эффекты многократной отправки. Так как в современных процессорах x86 есть (дайте-или-принять) три целых единицы, в общем случае можно отправить три команды за цикл.

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

Производительность Pentium 4 для 64-битных сдвигов вправо очень плохая. 64-битная сдвиг влево, а также все 32-битные сдвиги имеют приемлемую производительность. Похоже, что путь данных от верхних 32 битов к нижнему 32-биту ALU плохо разработан.

Я лично столкнулся с странным случаем, когда горячая линия работала значительно медленнее на ядре четырехъядерного чипа (AMD, если я помню). На самом деле мы получили лучшую производительность на карте - уменьшите расчет, отключив это ядро.

Здесь я догадываюсь о конкуренции за целые единицы: что счетчик popcnt, счетчик циклов и вычислений адресов могут просто работать на полной скорости с помощью 32-разрядного счетчика, но 64-разрядный счетчик вызывает конкуренцию и конвейер киоски. Поскольку всего всего около 12 циклов, потенциально 4 цикла с несколькими диспетчерами, на выполнение каждого цикла, один стойло может разумно повлиять на время выполнения в 2 раза.

Изменение, вызванное использованием статической переменной, которое, как я предполагаю, просто вызывает незначительное переупорядочение инструкций, является еще одним ключом к тому, что 32-битный код находится в какой-то точке перерыва для конкуренции.

Я знаю, что это не тщательный анализ, но это правдоподобное объяснение.

Вы пробовали передать -funroll-loops -fprefetch-loop-arrays в GCC?

Я получаю следующие результаты с этими дополнительными оптимизациями:

[1829] /tmp/so_25078285 $ cat /proc/cpuinfo |grep CPU|head -n1
model name      : Intel(R) Core(TM) i3-3225 CPU @ 3.30GHz
[1829] /tmp/so_25078285 $ g++ --version|head -n1
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

[1829] /tmp/so_25078285 $ g++ -O3 -march=native -std=c++11 test.cpp -o test_o3
[1829] /tmp/so_25078285 $ g++ -O3 -march=native -funroll-loops -fprefetch-loop-arrays -std=c++11     test.cpp -o test_o3_unroll_loops__and__prefetch_loop_arrays

[1829] /tmp/so_25078285 $ ./test_o3 1
unsigned        41959360000     0.595 sec       17.6231 GB/s
uint64_t        41959360000     0.898626 sec    11.6687 GB/s

[1829] /tmp/so_25078285 $ ./test_o3_unroll_loops__and__prefetch_loop_arrays 1
unsigned        41959360000     0.618222 sec    16.9612 GB/s
uint64_t        41959360000     0.407304 sec    25.7443 GB/s

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

Try:

  uint64_t subset_counts[4] = {};
  for( unsigned k = 0; k < 10000; k++){
     // Tight unrolled loop with unsigned
     unsigned i=0;
     while (i < size/8) {
        subset_counts[0] += _mm_popcnt_u64(buffer[i]);
        subset_counts[1] += _mm_popcnt_u64(buffer[i+1]);
        subset_counts[2] += _mm_popcnt_u64(buffer[i+2]);
        subset_counts[3] += _mm_popcnt_u64(buffer[i+3]);
        i += 4;
     }
  }
  count = subset_counts[0] + subset_counts[1] + subset_counts[2] + subset_counts[3];

У вас также есть странное сглаживание, что я не уверен, что он соответствует строгим правилам псевдонимов.

TL; DR: Вместо этого используйте __builtin intrinsics.

Я смог сделать gcc 4.8.4 (и даже 4.7.3 на gcc.godbolt.org) генерировать оптимальный код для этого, используя __builtin_popcountll, который использует ту же инструкцию сборки, но не имеет этого ошибка ложной зависимости.

Я не уверен на 100% моего кода бенчмаркинга, но вывод objdump, похоже, разделяет мои взгляды. Я использую некоторые другие трюки (++i vs i++), чтобы сделать цикл компиляции для меня без инструкции movl (странное поведение, я должен сказать).

Результаты:

Count: 20318230000  Elapsed: 0.411156 seconds   Speed: 25.503118 GB/s

Код бенчмаркинга:

#include <stdint.h>
#include <stddef.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>

uint64_t builtin_popcnt(const uint64_t* buf, size_t len){
  uint64_t cnt = 0;
  for(size_t i = 0; i < len; ++i){
    cnt += __builtin_popcountll(buf[i]);
  }
  return cnt;
}

int main(int argc, char** argv){
  if(argc != 2){
    printf("Usage: %s <buffer size in MB>\n", argv[0]);
    return -1;
  }
  uint64_t size = atol(argv[1]) << 20;
  uint64_t* buffer = (uint64_t*)malloc((size/8)*sizeof(*buffer));

  // Spoil copy-on-write memory allocation on *nix
  for (size_t i = 0; i < (size / 8); i++) {
    buffer[i] = random();
  }
  uint64_t count = 0;
  clock_t tic = clock();
  for(size_t i = 0; i < 10000; ++i){
    count += builtin_popcnt(buffer, size/8);
  }
  clock_t toc = clock();
  printf("Count: %lu\tElapsed: %f seconds\tSpeed: %f GB/s\n", count, (double)(toc - tic) / CLOCKS_PER_SEC, ((10000.0*size)/(((double)(toc - tic)*1e+9) / CLOCKS_PER_SEC)));
  return 0;
}

Параметры компиляции:

gcc --std=gnu99 -mpopcnt -O3 -funroll-loops -march=native bench.c -o bench

Версия GCC:

gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4

Версия ядра Linux:

3.19.0-58-generic

Информация о процессоре:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 70
model name  : Intel(R) Core(TM) i7-4870HQ CPU @ 2.50 GHz
stepping    : 1
microcode   : 0xf
cpu MHz     : 2494.226
cache size  : 6144 KB
physical id : 0
siblings    : 1
core id     : 0
cpu cores   : 1
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat pln pts dtherm fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid xsaveopt
bugs        :
bogomips    : 4988.45
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Хорошо, я хочу дать небольшой ответ на один из подвопросов, заданных ФП, которые, кажется, не рассматриваются в существующих вопросах. Предостережение: я не занимался ни тестированием, ни генерацией кода, ни дизассемблированием, просто хотел поделиться мыслью, которую другие могли бы разъяснить.

Почему static меняет производительность?

Рассматриваемая строка: uint64_t size = atol(argv[1])<<20;

Короткий ответ

Я бы посмотрел на сборку, сгенерированную для доступа к size и выяснил, есть ли дополнительные шаги по перенаправлению указателя, связанные с нестатической версией.

Длинный ответ

Поскольку существует только одна копия переменной, независимо от того, была ли она объявлена static или нет, а размер не изменился, я предполагаю, что различие заключается в расположении памяти, используемой для хранения переменной вместе с тем, где она используется в коде. дальше.

Хорошо, чтобы начать с очевидного, помните, что всем локальным переменным (вместе с параметрами) функции предоставляется место в стеке для использования в качестве хранилища. Теперь очевидно, что стек стека для main() никогда не очищается и генерируется только один раз. Хорошо, а как насчет того, чтобы сделать его static? Что ж, в этом случае компилятор знает, что нужно зарезервировать пространство в глобальном пространстве данных процесса, поэтому его местоположение не может быть очищено удалением стекового фрейма. Но, тем не менее, у нас есть только одно местоположение, так в чем же разница? Я подозреваю, что это связано с тем, как ссылки на ячейки памяти в стеке упоминаются.

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

Прежде всего, попытайтесь оценить пиковую производительность - изучите https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf В частности, Приложение С.

В вашем случае это таблица C-10, которая показывает, что инструкция POPCNT имеет задержку = 3 такта и пропускную способность = 1 такт. Пропускная способность показывает вашу максимальную скорость в тактах (умножьте на частоту ядра и 8 байтов в случае popcnt64, чтобы получить максимально возможное значение пропускной способности).

Теперь проверьте, что сделал компилятор, и суммируйте пропускную способность всех других инструкций в цикле. Это даст наилучшую оценку сгенерированного кода.

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

Однако в вашем случае правильное написание кода устранит все эти сложности. Вместо того, чтобы накапливаться в одной переменной count, просто накапливайте в разные (например, count0, count1,... count8) и суммируйте их в конце. Или даже создайте массив count [8] и накапливайте его элементы - возможно, он будет даже векторизован, и вы получите намного лучшую пропускную способность.

PS и никогда не запускайте эталонный тест в течение секунды, сначала прогрейте ядро, затем выполните цикл в течение по крайней мере 10 секунд или лучше 100 секунд. в противном случае вы протестируете аппаратное обеспечение управления питанием и реализацию DVFS аппаратно :)

PPS Я слышал бесконечные споры о том, сколько времени должно действительно пройти тест. Самые умные люди даже спрашивают, почему 10 секунд, а не 11 или 12. Я должен признать, что это забавно в теории. На практике вы просто стоите и запускаете бенчмарк сто раз подряд и записываете отклонения. Это смешно. Большинство людей меняют источник и запускают Bench после этого ровно ОДИН РАЗ, чтобы получить новый рекорд производительности. Делай правильные вещи правильно.

Еще не убежден? Просто используйте вышеупомянутую C-версию теста assp1r1n3 (https://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-counter-with-64-bit-introduces-crazy-performance-deviati) и попробуйте 100 вместо 10000 в цикле повтора.

Мой 7960X показывает, с RETRY = 100:

Счетчик: 203182300 Прошло: 0.008385 секунд Скорость: 12.505379 ГБ/с

Количество: 203182300 Прошло: 0,011063 секунды Скорость: 9,478225 ГБ/с

Количество: 203182300 Прошло: 0,011188 секунд Скорость: 9,372327 ГБ/с

Счетчик: 203182300 Прошло: 0,010393 с. Скорость: 10,089252 ГБ/с

Количество: 203182300 Прошло: 0,009076 секунд Скорость: 11,553283 ГБ/с

с RETRY = 10000:

Счетчик: 20318230000 Прошло: 0,661791 сек. Скорость: 15,844519 ГБ/с

Количество: 20318230000 Прошло: 0,665422 секунд Скорость: 15,758060 ГБ/с

Счетчик: 20318230000 Прошло: 0,660983 секунды. Скорость: 15,863888 ГБ/с.

Счетчик: 20318230000 Прошло: 0,665337 секунд. Скорость: 15,760073 ГБ/с.

Счетчик: 20318230000 Прошло: 0,662138 секунд Скорость: 15,836215 ГБ/с

PPPS Наконец-то о "принятом ответе" и других тайнах ;-)

Давайте воспользуемся ответом assp1r1n3 - у него ядро 2,5 ГГц. POPCNT имеет 1 тактовый выход, его код использует 64-битное popcnt. Таким образом, для его настройки математика составляет 2,5 ГГц * 1 тактовая частота * 8 байт = 20 ГБ/с. Он видит скорость 25 Гбит/с, возможно, из-за турбонаддува до 3 ГГц.

Таким образом, перейдите на ark.intel.com и найдите i7-4870HQ: https://ark.intel.com/products/83504/Intel-Core-i7-4870HQ-Processor-6M-Cache-up-to-3-70 -GHz-? д = i7-4870HQ

Это ядро может работать до 3,7 ГГц, а реальная максимальная скорость его оборудования составляет 29,6 ГБ/с. Так где еще 4Гб/с? Возможно, он расходуется на логику цикла и другой окружающий код в каждой итерации.

Где эта ложная зависимость? аппаратное обеспечение работает почти с максимальной скоростью. Может быть, моя математика плохая, иногда это случается :)

PPPPPS Тем не менее, люди, предположившие, что HW errata является виновником, поэтому я следую предложению и создаю пример встроенного ассемблера, см. Ниже.

На моем 7960X первая версия (с одним выходом для cnt0) работает со скоростью 11 МБ/с, вторая версия (с выходом для cnt0, cnt1, cnt2 и cnt3) работает со скоростью 33 МБ/с. И можно сказать - вуаля! это выходная зависимость.

Хорошо, возможно, я подчеркнул, что не имеет смысла писать код, подобный этому, и это не проблема выходных зависимостей, а глупая генерация кода. Мы не тестируем аппаратное обеспечение, мы пишем код для максимальной производительности. Вы можете ожидать, что HW OOO будет переименовывать и скрывать эти "выходные зависимости", но, gash, просто делайте правильные вещи правильно, и вы никогда не столкнетесь с какой-либо загадкой.

uint64_t builtin_popcnt1a(const uint64_t* buf, size_t len) 
{
    uint64_t cnt0, cnt1, cnt2, cnt3;
    cnt0 = cnt1 = cnt2 = cnt3 = 0;
    uint64_t val = buf[0];
    #if 0
        __asm__ __volatile__ (
            "1:\n\t"
            "popcnt %2, %1\n\t"
            "popcnt %2, %1\n\t"
            "popcnt %2, %1\n\t"
            "popcnt %2, %1\n\t"
            "subq $4, %0\n\t"
            "jnz 1b\n\t"
        : "+q" (len), "=q" (cnt0)
        : "q" (val)
        :
        );
    #else
        __asm__ __volatile__ (
            "1:\n\t"
            "popcnt %5, %1\n\t"
            "popcnt %5, %2\n\t"
            "popcnt %5, %3\n\t"
            "popcnt %5, %4\n\t"
            "subq $4, %0\n\t"
            "jnz 1b\n\t"
        : "+q" (len), "=q" (cnt0), "=q" (cnt1), "=q" (cnt2), "=q" (cnt3)
        : "q" (val)
        :
        );
    #endif
    return cnt0;
}