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

Я искал самый быстрый способ для больших массивов данных popcount. Я столкнулся с очень странным эффектом: изменение переменной цикла от unsigned до uint64_t привело к снижению производительности на 50% на моем ПК.

Контрольный показатель

#include <iostream>
#include <chrono>
#include <x86intrin.h>

int main(int argc, char* argv[]) {

    using namespace std;
    if (argc != 2) {
       cerr << "usage: array_size in MB" << endl;
       return -1;
    }

    uint64_t size = atol(argv[1])<<20;
    uint64_t* buffer = new uint64_t[size/8];
    char* charbuffer = reinterpret_cast<char*>(buffer);
    for (unsigned i=0; i<size; ++i)
        charbuffer[i] = rand()%256;

    uint64_t count,duration;
    chrono::time_point<chrono::system_clock> startP,endP;
    {
        startP = chrono::system_clock::now();
        count = 0;
        for( unsigned k = 0; k < 10000; k++){
            // Tight unrolled loop with unsigned
            for (unsigned i=0; i<size/8; i+=4) {
                count += _mm_popcnt_u64(buffer[i]);
                count += _mm_popcnt_u64(buffer[i+1]);
                count += _mm_popcnt_u64(buffer[i+2]);
                count += _mm_popcnt_u64(buffer[i+3]);
            }
        }
        endP = chrono::system_clock::now();
        duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
        cout << "unsigned\t" << count << '\t' << (duration/1.0E9) << " sec \t"
             << (10000.0*size)/(duration) << " GB/s" << endl;
    }
    {
        startP = chrono::system_clock::now();
        count=0;
        for( unsigned k = 0; k < 10000; k++){
            // Tight unrolled loop with uint64_t
            for (uint64_t i=0;i<size/8;i+=4) {
                count += _mm_popcnt_u64(buffer[i]);
                count += _mm_popcnt_u64(buffer[i+1]);
                count += _mm_popcnt_u64(buffer[i+2]);
                count += _mm_popcnt_u64(buffer[i+3]);
            }
        }
        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;
    }

    free(charbuffer);
}

Как вы видите, мы создаем буфер случайных данных с размером x мегабайт, где x считывается из командной строки. Затем мы перебираем буфер и используем развернутую версию x86 popcount, чтобы выполнить popcount. Чтобы получить более точный результат, мы делаем 10000 раз. Мы измеряем время для popcount. В верхнем регистре внутренняя переменная цикла unsigned, в нижнем регистре внутренняя переменная цикла uint64_t. Я думал, что это не имеет значения, но дело обстоит наоборот.

Результаты (абсолютно безумные)

Я скомпилирую его следующим образом (версия g++: Ubuntu 4.8.2-19ubuntu1):

g++ -O3 -march=native -std=c++11 test.cpp -o test

Вот результаты на моем Haswell Core i7-4770K CPU @3.50 GHz, запуск test 1 (так что 1 случайные данные MB):

  • unsigned 41959360000 0.401554 sec 26.113 GB/s
  • uint64_t 41959360000 0,759822 сек 13.8003 GB/s

Как вы видите, пропускная способность версии uint64_t только наполовину - одна из версий unsigned! Проблема заключается в том, что генерируется другая сборка, но почему? Во-первых, я подумал о ошибке компилятора, поэтому я попробовал clang++ (Ubuntu Clang версия 3.4-1ubuntu3):

clang++ -O3 -march=native -std=c++11 teest.cpp -o test

Результат: test 1

  • unsigned 41959360000 0.398293 sec 26.3267 Гб/с
  • uint64_t 41959360000 0.680954 sec 15.3986 Гб/с

Итак, это почти тот же результат и по-прежнему странный. Но теперь это становится супер странным. Я заменяю размер буфера, который был прочитан с ввода с константой 1, поэтому я меняю:

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

к

uint64_t size = 1 << 20;

Таким образом, компилятор теперь знает размер буфера во время компиляции. Возможно, он может добавить некоторые оптимизации! Вот цифры для g++:

  • unsigned 41959360000 0.509156 sec 20.5944 GB/s
  • uint64_t 41959360000 0.508673 sec 20.6139 GB/s

Теперь обе версии одинаково быстры. Однако unsigned получил еще медленнее! Он упал с 26 до 20 GB/s, таким образом, заменив непостоянное на постоянное значение, приведет к деоптимизации. Серьезно, я понятия не имею, что здесь происходит! Но теперь до clang++ с новой версией:

  • unsigned 41959360000 0.677009 sec 15.4884 GB/s
  • uint64_t 41959360000 0,676909 сек 15.4906 GB/s

Подождите, что? Теперь обе версии упали до медленного числа в 15 бит/с. Таким образом, замена непостоянного на постоянное значение даже приводит к медленному коду в случаях для Clang!

Я попросил коллегу с CPU

1179
задан 01 авг. '14 в 13:33
источник поделиться
8 ответов

Culprit: False Зависимость данных (и компилятор даже не знает об этом)

В процессорах Sandy/Ivy Bridge и Haswell инструкция:

popcnt  src, dest

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

Эта зависимость не просто удерживает 4 popcnt от одной итерации цикла. Он может переносить чередующиеся итерации цикла, что делает невозможным параллельное использование процессором разных итераций цикла.

unsigned vs. uint64_t и другие твики не влияют непосредственно на проблему. Но они влияют на распределитель регистров, который присваивает регистры переменным.

В вашем случае скорости являются прямым результатом того, что застряло в цепочке зависимостей (false) в зависимости от того, что решило сделать распределитель регистров.

  • 13 ГБ/с имеет цепочку: popcnt - add - popcnt - popcnt → следующая итерация
  • 15 ГБ/с имеет цепочку: popcnt - add - popcnt - add → следующая итерация
  • 20 ГБ/с имеет цепочку: popcnt - popcnt → следующая итерация
  • 26 ГБ/с имеет цепочку: popcnt - popcnt → следующая итерация

Разница между 20 ГБ/с и 26 ГБ/с кажется незначительным артефактом косвенной адресации. В любом случае, процессор начинает ударять по другим узким местам, как только вы достигнете этой скорости.


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

Вот результаты:

Sandy Bridge Xeon @3.5 ГГц: (полный тестовый код можно найти внизу)

  • GCC 4.6.3: g++ popcnt.cpp -std=c++0x -O3 -save-temps -march=native
  • Ubuntu 12

Различные регистры: 18.6195 Гб/с

.L4:
    movq    (%rbx,%rax,8), %r8
    movq    8(%rbx,%rax,8), %r9
    movq    16(%rbx,%rax,8), %r10
    movq    24(%rbx,%rax,8), %r11
    addq    $4, %rax

    popcnt %r8, %r8
    add    %r8, %rdx
    popcnt %r9, %r9
    add    %r9, %rcx
    popcnt %r10, %r10
    add    %r10, %rdi
    popcnt %r11, %r11
    add    %r11, %rsi

    cmpq    $131072, %rax
    jne .L4

Тот же регистр: 8.49272 ГБ/с

.L9:
    movq    (%rbx,%rdx,8), %r9
    movq    8(%rbx,%rdx,8), %r10
    movq    16(%rbx,%rdx,8), %r11
    movq    24(%rbx,%rdx,8), %rbp
    addq    $4, %rdx

    # This time reuse "rax" for all the popcnts.
    popcnt %r9, %rax
    add    %rax, %rcx
    popcnt %r10, %rax
    add    %rax, %rsi
    popcnt %r11, %rax
    add    %rax, %r8
    popcnt %rbp, %rax
    add    %rax, %rdi

    cmpq    $131072, %rdx
    jne .L9

Тот же регистр со сломанной цепочкой: 17.8869 Гб/с

.L14:
    movq    (%rbx,%rdx,8), %r9
    movq    8(%rbx,%rdx,8), %r10
    movq    16(%rbx,%rdx,8), %r11
    movq    24(%rbx,%rdx,8), %rbp
    addq    $4, %rdx

    # Reuse "rax" for all the popcnts.
    xor    %rax, %rax    # Break the cross-iteration dependency by zeroing "rax".
    popcnt %r9, %rax
    add    %rax, %rcx
    popcnt %r10, %rax
    add    %rax, %rsi
    popcnt %r11, %rax
    add    %rax, %r8
    popcnt %rbp, %rax
    add    %rax, %rdi

    cmpq    $131072, %rdx
    jne .L14

Итак, что пошло не так с компилятором?

Кажется, что ни GCC, ни Visual Studio не знают, что popcnt имеет такую ​​ложную зависимость. Тем не менее, эти ложные зависимости не редкость. Это просто вопрос о том, знает ли компилятор об этом.

popcnt - не совсем самая используемая инструкция. Поэтому не удивительно, что крупный компилятор мог пропустить что-то вроде этого. Там также нет документации, где упоминается эта проблема. Если Intel не раскроет это, никто из них не узнает, пока кто-то не столкнется с ним случайно.

( Обновление: Начиная с версии 4.9.2, GCC знает об этой ложной зависимости и генерирует код, чтобы компенсировать его при оптимизации. Крупные компиляторы от других поставщиков, включая Clang, MSVC и даже Intel ICC, еще не знают об этом микроархитектурном erratum и не будут испускать код, который его компенсирует.)

Почему у процессора есть такая ложная зависимость?

Мы можем только догадываться, но, скорее всего, у Intel есть такая же обработка для множества инструкций с двумя операндами. Общие инструкции типа add, sub принимают два операнда, оба из которых являются входами. Так что Intel, вероятно, запустил popcnt в ту же категорию, чтобы упростить дизайн процессора.

Процессоры AMD, похоже, не имеют этой ложной зависимости.


Полный тестовый код приведен ниже для справки:

#include <iostream>
#include <chrono>
#include <x86intrin.h>

int main(int argc, char* argv[]) {

   using namespace std;
   uint64_t size=1<<20;

   uint64_t* buffer = new uint64_t[size/8];
   char* charbuffer=reinterpret_cast<char*>(buffer);
   for (unsigned i=0;i<size;++i) charbuffer[i]=rand()%256;

   uint64_t count,duration;
   chrono::time_point<chrono::system_clock> startP,endP;
   {
      uint64_t c0 = 0;
      uint64_t c1 = 0;
      uint64_t c2 = 0;
      uint64_t c3 = 0;
      startP = chrono::system_clock::now();
      for( unsigned k = 0; k < 10000; k++){
         for (uint64_t i=0;i<size/8;i+=4) {
            uint64_t r0 = buffer[i + 0];
            uint64_t r1 = buffer[i + 1];
            uint64_t r2 = buffer[i + 2];
            uint64_t r3 = buffer[i + 3];
            __asm__(
                "popcnt %4, %4  \n\t"
                "add %4, %0     \n\t"
                "popcnt %5, %5  \n\t"
                "add %5, %1     \n\t"
                "popcnt %6, %6  \n\t"
                "add %6, %2     \n\t"
                "popcnt %7, %7  \n\t"
                "add %7, %3     \n\t"
                : "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
                : "r"  (r0), "r"  (r1), "r"  (r2), "r"  (r3)
            );
         }
      }
      count = c0 + c1 + c2 + c3;
      endP = chrono::system_clock::now();
      duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
      cout << "No Chain\t" << count << '\t' << (duration/1.0E9) << " sec \t"
            << (10000.0*size)/(duration) << " GB/s" << endl;
   }
   {
      uint64_t c0 = 0;
      uint64_t c1 = 0;
      uint64_t c2 = 0;
      uint64_t c3 = 0;
      startP = chrono::system_clock::now();
      for( unsigned k = 0; k < 10000; k++){
         for (uint64_t i=0;i<size/8;i+=4) {
            uint64_t r0 = buffer[i + 0];
            uint64_t r1 = buffer[i + 1];
            uint64_t r2 = buffer[i + 2];
            uint64_t r3 = buffer[i + 3];
            __asm__(
                "popcnt %4, %%rax   \n\t"
                "add %%rax, %0      \n\t"
                "popcnt %5, %%rax   \n\t"
                "add %%rax, %1      \n\t"
                "popcnt %6, %%rax   \n\t"
                "add %%rax, %2      \n\t"
                "popcnt %7, %%rax   \n\t"
                "add %%rax, %3      \n\t"
                : "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
                : "r"  (r0), "r"  (r1), "r"  (r2), "r"  (r3)
                : "rax"
            );
         }
      }
      count = c0 + c1 + c2 + c3;
      endP = chrono::system_clock::now();
      duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
      cout << "Chain 4   \t"  << count << '\t' << (duration/1.0E9) << " sec \t"
            << (10000.0*size)/(duration) << " GB/s" << endl;
   }
   {
      uint64_t c0 = 0;
      uint64_t c1 = 0;
      uint64_t c2 = 0;
      uint64_t c3 = 0;
      startP = chrono::system_clock::now();
      for( unsigned k = 0; k < 10000; k++){
         for (uint64_t i=0;i<size/8;i+=4) {
            uint64_t r0 = buffer[i + 0];
            uint64_t r1 = buffer[i + 1];
            uint64_t r2 = buffer[i + 2];
            uint64_t r3 = buffer[i + 3];
            __asm__(
                "xor %%rax, %%rax   \n\t"   // <--- Break the chain.
                "popcnt %4, %%rax   \n\t"
                "add %%rax, %0      \n\t"
                "popcnt %5, %%rax   \n\t"
                "add %%rax, %1      \n\t"
                "popcnt %6, %%rax   \n\t"
                "add %%rax, %2      \n\t"
                "popcnt %7, %%rax   \n\t"
                "add %%rax, %3      \n\t"
                : "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
                : "r"  (r0), "r"  (r1), "r"  (r2), "r"  (r3)
                : "rax"
            );
         }
      }
      count = c0 + c1 + c2 + c3;
      endP = chrono::system_clock::now();
      duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
      cout << "Broken Chain\t"  << count << '\t' << (duration/1.0E9) << " sec \t"
            << (10000.0*size)/(duration) << " GB/s" << endl;
   }

   free(charbuffer);
}

Не менее интересный бенчмарк можно найти здесь: http://pastebin.com/kbzgL8si
Этот критерий изменяет количество popcnt, которые находятся в цепочке зависимостей (false).

False Chain 0:  41959360000 0.57748 sec     18.1578 GB/s
False Chain 1:  41959360000 0.585398 sec    17.9122 GB/s
False Chain 2:  41959360000 0.645483 sec    16.2448 GB/s
False Chain 3:  41959360000 0.929718 sec    11.2784 GB/s
False Chain 4:  41959360000 1.23572 sec     8.48557 GB/s
1339
ответ дан 02 авг. '14 в 1:41
источник

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

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

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

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

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

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

47
ответ дан 02 авг. '14 в 1:55
источник

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

Я получаю эти результаты с помощью 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-бит быстрее.

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

24
ответ дан 01 авг. '14 в 14:04
источник

Я попробовал это с 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
10
ответ дан 02 авг. '14 в 6:48
источник

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

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

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

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

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

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

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

10
ответ дан 01 авг. '14 в 23:12
источник

Вы пробовали передать -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
9
ответ дан 04 авг. '14 в 18:37
источник

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

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];

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

7
ответ дан 01 авг. '14 в 21:33
источник

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:
6
ответ дан 04 мая '16 в 14:14
источник

Другие вопросы по меткам или Задайте вопрос