если вы считаете, что 64-битная инструкция DIV-хороший способ разделить на два, то неудивительно, что вывод ASM компилятора побил ваш рукописный код, даже с -O0 (скомпилируйте быстро, без дополнительной оптимизации и сохраните / перезагрузите в память после / перед каждым оператором C, чтобы отладчик мог изменять переменные).

посмотреть руководство по оптимизации сборки Agner Fog чтобы узнать, как писать эффективный asm. Он также имеет таблицы инструкций и руководство microarch для конкретных деталей для конкретные процессоры. См. также x86 tag wiki для получения дополнительных ссылок perf.

см. Также этот более общий вопрос об избиении компилятора с помощью рукописного asm:является ли встроенный язык сборки медленнее, чем собственный код c++?. TL: DR: да, если вы делаете это неправильно (например, этот вопрос).

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

even:
    mov rbx, 2
    xor rdx, rdx
    div rbx

На Intel Haswell,div r64 36 uops, с задержка 32-96 циклов, и объем одного в 21-74 цикла. (Плюс 2 uops для настройки RBX и нулевого RDX, но выполнение вне заказа может запустить их раньше). High-uop-count инструкции, такие как DIV, микрокодируются, что также может вызвать узкие места на переднем конце. в этом случае латентность является наиболее релевантным фактором, поскольку она является частью цепочки зависимостей с циклом.

shr rax, 1 делает то же самое беззнаковое деление: это 1 uop, с задержкой 1c, и может побежать 2 в такт.

для сравнения, 32-битное деление быстрее, но все равно ужасно против сдвигов. idiv r32 9 uops, задержка 22-29c, и один в Пропускная способность 8-11c на Haswell.

как вы можете видеть, глядя на gcc -O0 выход asm (проводник компилятора Godbolt), он использует только инструкции смены. лязг!--5--> компилируется наивно, как вы думали, даже используя 64-битный IDIV дважды. (При оптимизации компиляторы используют оба выхода IDIV, когда источник выполняет деление и модуль с теми же операндами, если они вообще используют IDIV)

GCC не имеет совершенно наивный режим;он всегда преобразуется через GIMPLE, что означает, что некоторые "оптимизации" не могут быть отключены. Это включает в себя распознавание деления на константу и использование сдвигов (мощность 2) или мультипликативный обратный с фиксированной точкой (не мощность 2), чтобы избежать IDIV (см. div_by_13 в приведенной выше ссылке godbolt).

gcc -Os (оптимизация по размеру) тут используйте IDIV для разделения non-power-of-2, к сожалению, даже в тех случаях, когда мультипликативный обратный код лишь немного больше, но намного быстрее.

помощь компилятору

(резюме для этого случая: используйте uint64_t n)

прежде всего, интересно только посмотреть на оптимизированный вывод компилятора. (-O3). -O0 скорость в принципе бессмысленно.

посмотрите на выход asm (на Godbolt или см. Как удалить " шум " из сборки GCC / clang выход?). Когда компилятор не делает оптимальный код в первую очередь:написание источника C/C++ таким образом, чтобы компилятор делал лучший код, как правило, лучший подход. Вы должны знать asm и знать, что эффективно, но вы применяете это знание косвенно. Компиляторы также являются хорошим источником идей: иногда clang сделает что-то классное, и вы можете вручную удерживать gcc, делая то же самое: см. ответ и то, что я сделал с не развернутый цикл в коде @Veedrac ниже.)

этот подход переносим, и через 20 лет какой-то будущий компилятор может скомпилировать его на все, что эффективно на будущем оборудовании (x86 или нет), возможно, используя новое расширение ISA или авто-векторизацию. Рукописный x86-64 asm от 15 лет назад, как правило, не будет оптимально настроен для Skylake. например, compare & branch macro-fusion тогда не существовало. что оптимально сейчас для ручной asm для одной микроархитектуры может не быть оптимально для других текущих и будущих процессоров. комментарии на ответ @johnfound это обсудите основные различия между AMD Bulldozer и Intel Haswell, которые оказывают большое влияние на этот код. Но теоретически,g++ -O3 -march=bdver3 и g++ -O3 -march=skylake поступит правильно. (Или -march=native.) Или -mtune=... просто настроить, без использования инструкций, которые другие процессоры могут не поддерживать.

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

написанный от руки asm черный ящик для оптимизатор, поэтому постоянное распространение не работает, когда inlining делает вход константой времени компиляции. Другие оптимизации также затронуты. Читать https://gcc.gnu.org/wiki/DontUseInlineAsm перед использованием asm. (И избегайте встроенного asm в стиле MSVC: входы / выходы должны проходить через память что добавляет накладные расходы.)

в этом случае: ваш n имеет подписанный тип, и gcc использует последовательность SAR / SHR / ADD, которая дает правильный округление. (IDIV и арифметический сдвиг "круглый" по-разному для отрицательных входов, см. SAR insn set ref ручной ввод). (IDK, если gcc попытался и не смог доказать это n не может быть отрицательным, или что. Signed-overflow-это неопределенное поведение, поэтому оно должно было быть в состоянии.)

вы должны использовать uint64_t n, поэтому он может просто SHR. И поэтому он переносится в системы, где long только 32-разрядный (например, x86-64 Windows).

BTW, ССАГПЗ оптимизация выход asm выглядит довольно хорошо (используя unsigned long n): внутренняя петля он выстраивается в main() это:

 # from gcc5.4 -O3  plus my comments

 # edx= count=1
 # rax= uint64_t n

.L9:                   # do{
    lea    rcx, [rax+1+rax*2]   # rcx = 3*n + 1
    mov    rdi, rax
    shr    rdi         # rdi = n>>1;
    test   al, 1       # set flags based on n%2 (aka n&1)
    mov    rax, rcx
    cmove  rax, rdi    # n= (n%2) ? 3*n+1 : n/2;
    add    edx, 1      # ++count;
    cmp    rax, 1
    jne   .L9          #}while(n!=1)

  cmp/branch to update max and maxi, and then do the next n

внутренний цикл не имеет ветвей, а критический путь цепочки зависимостей с петлей:

• 3-компонентный LEA (3 цикла)
• cmov (2 цикла на Haswell, 1c на Broadwell или более поздней версии).

Итого: 5 циклов на итерацию, задержка узкое место. Выполнение вне порядка заботится обо всем остальном параллельно с этим (теоретически: я не тестировал счетчики perf, чтобы увидеть, действительно ли он работает на 5c/iter).

флаги ввода cmov (произведенный тестом) быстрее производить, чем вход RAX (от LEA->MOV), поэтому он не находится на критическом пути.

аналогично, MOV - >SHR, который производит вход RDI CMOV, находится вне критического пути, потому что он также быстрее, чем LEA. MOV on IvyBridge и позже имеет нулевую задержку (обрабатывается во время регистрации-переименования). (Он по-прежнему занимает uop и слот в конвейере, поэтому он не свободен, просто нулевая задержка). Дополнительный MOV в цепи LEA dep является частью узкого места на других процессорах.

cmp / jne также не является частью критического пути: он не переносится по циклу, потому что зависимости управления обрабатываются с предсказанием ветви + спекулятивным выполнением, в отличие от зависимостей данных на критическом пути.

избиение компилятор

GCC проделал здесь неплохую работу. Он может сохранить один байт кода, используя inc edx вместо add edx, 1, потому что никто не заботится о P4 и его ложных зависимостях для инструкций частичного изменения флага.

он также может сохранить все инструкции MOV и тест: SHR устанавливает CF= бит сдвинут, поэтому мы можем использовать cmovc вместо test / cmovz.

 ### Hand-optimized version of what gcc does
.L9:                       #do{
    lea     rcx, [rax+1+rax*2] # rcx = 3*n + 1
    shr     rax, 1         # n>>=1;    CF = n&1 = n%2
    cmovc   rax, rcx       # n= (n&1) ? 3*n+1 : n/2;
    inc     edx            # ++count;
    cmp     rax, 1
    jne     .L9            #}while(n!=1)

см. ответ @johnfound для другого умного трюк: удалите CMP, разветвив результат флага SHR, а также используя его для CMOV: ноль, только если N было 1 (или 0) для начала. (Забавный факт: SHR с графом != 1 на Nehalem или ранее вызывает остановку, если Вы читаете результаты флага. Вот как они сделали это один-uop. Однако специальная кодировка shift-by-1 в порядке.)

избегание MOV не помогает с задержкой вообще на Haswell (может ли движение x86 действительно быть "свободным"? Почему я не могу воспроизвести это в все?). Это помогает значительно на процессорах, таких как Intel pre-IvB и AMD Bulldozer-family, где MOV не имеет нулевой задержки. Потерянные инструкции MOV компилятора влияют на критический путь. Комплекс BD-LEA и CMOV имеют более низкую задержку (2c и 1c соответственно), поэтому это большая часть задержки. Кроме того, узкие места пропускной способности становятся проблемой, потому что он имеет только два целочисленных канала ALU. посмотреть @johnfound ответ, где у него есть результаты сроки от процессора AMD.

даже на Haswell эта версия может немного помочь, избегая некоторых случайных задержек, когда некритический uop крадет порт выполнения от одного на критическом пути, задерживая выполнение на 1 цикл. (Это называется конфликтом ресурсов). Он также сохраняет регистр, который может помочь при выполнении нескольких n значения параллельно в чередующемся цикле (см. ниже).

задержка LEA зависит от режима адресации, на Intel SnB-семья ЦПУ. 3c для 3 компонентов ([base+idx+const], что занимает два отдельных добавления), но только 1С с 2 или менее компонентами (одно добавление). Некоторые процессоры (например, Core2) делают даже 3-компонентный LEA в одном цикле, но SnB-семейство этого не делает. Хуже,Intel SnB-family стандартизирует задержки, поэтому нет 2c uops, иначе 3-компонентный LEA будет только 2c, как бульдозер. (3-компонентный LEA также медленнее на AMD, просто не так сильно).

так lea rcx, [rax + rax*2] / inc rcx только задержка 2c, быстрее, чем lea rcx, [rax + rax*2 + 1], на процессорах Intel SnB-family, таких как Haswell. Безубыточность на BD, и хуже на Core2. Это стоит дополнительного uop, который обычно не стоит того, чтобы сохранить задержку 1c, но задержка является основным узким местом здесь, и Haswell имеет достаточно широкий конвейер для обработки дополнительной пропускной способности uop.

ни gcc, icc, ни clang (на godbolt) не использовали выход CF SHR, всегда используя AND или TEST. Глупые компиляторы. : P они большие части сложной машины, но a умный человек часто может победить их в мелких проблемах. (Конечно, если подумать об этом в тысячи-миллионы раз дольше! Компиляторы не используют исчерпывающие алгоритмы для поиска всех возможных способов, потому что это займет слишком много времени при оптимизации большого количества встроенного кода, что они делают лучше всего. Они также не моделируют конвейер в целевой микроархитектуре, по крайней мере, не так подробно, как IACA или другие инструменты статического анализа; они просто используют немного эвристики.)

простое развертывание цикла не поможет; это узкие места цикла на задержке цепи зависимостей с циклом, а не на накладных расходах / пропускной способности цикла. Это означает, что он будет хорошо работать с hyperthreading (или любым другим видом SMT), так как процессор имеет много времени для чередования инструкций из двух потоков. Это означало бы распараллеливание цикла в main, но это нормально, потому что каждый поток может просто проверить ряд n ценности и в результате получается пара целых чисел.

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

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

вы могли бы даже сделать это с SSE packed-сравнить материал, чтобы условно увеличить счетчик для векторных элементов, где n не дошло 1 еще. А затем, чтобы скрыть еще большую задержку реализации условного приращения SIMD, вам нужно будет сохранить больше векторов n значения в воздух. Возможно, стоит только с вектором 256b (4x uint64_t).

я думаю, что лучшая стратегия, чтобы сделать обнаружение 1 "sticky" -это маска вектора всех, которые вы добавляете для увеличения счетчика. Так что после вы видели 1 в элементе вектор приращения будет иметь ноль, а +=0 - нет.

непроверенная идея для ручной векторизации

# starting with YMM0 = [ n_d, n_c, n_b, n_a ]  (64-bit elements)
# ymm4 = _mm256_set1_epi64x(1):  increment vector
# ymm5 = all-zeros:  count vector

.inner_loop:
    vpaddq    ymm1, ymm0, xmm0
    vpaddq    ymm1, ymm1, xmm0
    vpaddq    ymm1, ymm1, set1_epi64(1)     # ymm1= 3*n + 1.  Maybe could do this more efficiently?

    vprllq    ymm3, ymm0, 63                # shift bit 1 to the sign bit

    vpsrlq    ymm0, ymm0, 1                 # n /= 2

    # There may be a better way to do this blend, avoiding the bypass delay for an FP blend between integer insns, not sure.  Probably worth it
    vpblendvpd ymm0, ymm0, ymm1, ymm3       # variable blend controlled by the sign bit of each 64-bit element.  I might have the source operands backwards, I always have to look this up.

    # ymm0 = updated n  in each element.

    vpcmpeqq ymm1, ymm0, set1_epi64(1)
    vpandn   ymm4, ymm1, ymm4         # zero out elements of ymm4 where the compare was true

    vpaddq   ymm5, ymm5, ymm4         # count++ in elements where n has never been == 1

    vptest   ymm4, ymm4
    jnz  .inner_loop
    # Fall through when all the n values have reached 1 at some point, and our increment vector is all-zero

    vextracti128 ymm0, ymm5, 1
    vpmaxq .... crap this doesn't exist
    # Actually just delay doing a horizontal max until the very very end.  But you need some way to record max and maxi.

вы можете и должны реализовать это с помощью встроенных, а не рукописных asm.

улучшение Алгоритмики / реализации:

помимо реализации той же логики с более эффективным asm, ищите способы упростить логику или избежать избыточной работы. например, memoize для обнаружения общих окончаний последовательностей. Или даже лучше, посмотрите на 8 трейлинг-бит сразу (ответ гнашера)--66-->

@EOF указывает, что tzcnt (или bsf) могут использоваться для выполнения нескольких n/=2 итерации в один шаг. Это, вероятно, лучше, чем векторизация SIMD, потому что никакая инструкция SSE или AVX не может этого сделать. Он по-прежнему совместим с выполнением нескольких скалярных ns параллельно в разных целочисленных регистрах.

таким образом, цикл может выглядеть так:

goto loop_entry;  // C++ structured like the asm, for illustration only
do {
   n = n*3 + 1;
  loop_entry:
   shift = _tzcnt_u64(n);
   n >>= shift;
   count += shift;
} while(n != 1);

это может сделать значительно меньше итераций, но количество переменных сдвиги медленны на процессорах семейства Intel SnB без BMI2. 3 uops, задержка 2С. (Они имеют входную зависимость от флагов, потому что count=0 означает, что флаги не изменяются. Они обрабатывают это как зависимость данных и принимают несколько UOP, потому что uop может иметь только 2 входа (pre-HSW/BDW в любом случае)). Это тот вид, на который ссылаются люди, жалующиеся на сумасшедший дизайн x86-CISC. Это делает процессоры x86 медленнее, чем они были бы, если бы ISA был разработан с нуля сегодня, даже в основном похожем путь. (т. е. это часть "налога x86", который стоит скорости / мощности.) SHRX/SHLX / SARX (BMI2) - большая победа (1 задержка uop / 1c).

он также помещает tzcnt (3c на Haswell и позже) на критический путь, поэтому он значительно удлиняет общую задержку цепи зависимостей, переносимых циклом. Это устраняет любую потребность в CMOV, или для подготовки реестра холдинг n>>1, хотя. @Veedrac's answer преодолевает все это, откладывая tzcnt / shift для нескольких итераций, которые является высокоэффективным (см. ниже).

мы можем безопасно использовать BSF или TZCNT взаимозаменяемо, потому что n никогда не может быть нулем в этот момент. Машинный код TZCNT декодируется как BSF на процессорах, которые не поддерживают BMI1. (Бессмысленные префиксы игнорируются, поэтому REP BSF работает как BSF).

TZCNT работает намного лучше, чем BSF на процессорах AMD, которые его поддерживают, поэтому может быть хорошей идеей использовать REP BSF, даже если вы не заботитесь о настройке ZF если вход равен нулю, а не выходу. Некоторые компиляторы делают это при использовании __builtin_ctzll даже -mno-bmi.

они выполняют то же самое на процессорах Intel, поэтому просто сохраните байт, если это все, что имеет значение. TZCNT на Intel (pre-Skylake) по-прежнему имеет ложную зависимость от предположительно только для записи выходного операнда, как и BSF, для поддержки недокументированного поведения, которое BSF с input = 0 оставляет его назначение неизменным. Поэтому вам нужно обойти это, если оптимизация только для Skylake, так что нет ничего, чтобы получить от дополнительного байта повторения. (Intel часто выходит за рамки того, что требует руководство x86 ISA, чтобы избежать взлома широко используемого кода, который зависит от чего-то, что он не должен, или что ретроактивно запрещено. например,Windows 9x не предполагает спекулятивной предварительной выборки записей TLB, что было безопасно, когда код был написан,до того, как Intel обновила правила управления TLB.)

в любом случае, LZCNT / TZCNT на Haswell есть тот же false dep, что и POPCNT: см. это Q & A. Вот почему в asm-выходе gcc для кода @Veedrac вы видите его разрыв цепи dep с XOR-обнулением в реестре он собирается использовать в качестве пункта назначения TZCNT, когда он не использует dst=src. Поскольку TZCNT / LZCNT / POPCNT никогда не оставляют свое назначение неопределенным или немодифицированным, эта ложная зависимость от вывода на процессорах Intel является чисто ошибкой / ограничением производительности. Предположительно, это стоит некоторых транзисторов / мощности пусть они ведут себя как другие uops, которые идут в ту же единицу выполнения. Единственный программно-видимый плюс заключается во взаимодействии с другим микроархитектурным ограничением:они могут микро-сплавить операнд памяти с индексированным режимом адресации на Haswell, но на Skylake, где Intel удалила ложную зависимость для lzcnt / TZCNT, они "не ламинируют" индексированные режимы адресации, в то время как POPCNT все еще может микро-плавить любой режим addr.

улучшения идей / кода от другие ответы:

@hidefromkgb ответ имеет хорошее наблюдение, что вы гарантированно сможете сделать одну правую смену после 3n+1. Вы можете вычислить это еще более эффективно, чем просто оставляя проверки между шагами. Однако реализация asm в этом ответе нарушена (это зависит от OF, который не определен после SHRD с count > 1) и медленный: ROR rdi,2 быстрее SHRD rdi,rdi,2, и использование двух инструкций CMOV на критическом пути медленнее чем дополнительный тест, который может выполняться параллельно.

я поставил tidied / improved C (который направляет компилятор для создания лучшего asm) и протестировал+работает быстрее asm (в комментариях ниже C) на Godbolt: см. ссылку в @hidefromkgb ответ. (Этот ответ попал в предел 30K char из больших URL-адресов Godbolt, но короткие ссылки могут гнить и были слишком длинными для слизи.во всяком случае, gl.)

также улучшен вывод-печать для преобразования в строку и сделайте один write() вместо того, чтобы писать по одному символу за раз. Это минимизирует влияние на синхронизацию всей программы с perf stat ./collatz (для записи счетчиков производительности), и я де-запутал некоторые из некритических asm.

код @ Veedrac

я получил очень небольшое ускорение от правого переключения столько, сколько мы знаю необходимо сделать и проверить, чтобы продолжить цикл. От 7.5 s Для предела=1e8 вниз к 7.275 s, на Core2Duo( Merom), с раскатать коэффициент 16.

код + комментарии на Godbolt. Не используйте эту версию с clang; он делает что-то глупое с отложенным циклом. Использование счетчика tmp k и затем добавить его в count потом какой-то лязг, но немного hurts gcc.

см. обсуждение в комментариях: код Veedrac отлично на процессорах с BMI1 (т. е. не Celeron/Pentium)