Проверка параметров умножения на константу в 64 бит

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

gcc реализует unsigned 64bit divmod с константой 0x28f5c28f5c28f5c3. Я не рассматривал подробно генерацию констант для деления, но есть алгоритмы для их генерации, которые дадут известные хорошие результаты (поэтому исчерпывающее тестирование не является необходимый.)

код на самом деле имеет несколько важных отличий: он использует константу иначе, чем константа OP.

см. комментарии для анализа того, что это на самом деле делает: сначала разделите на 4, чтобы он мог использовать константу, которая работает только для деления на 25, когда дивиденд достаточно мал. Это также позволяет избежать необходимости добавления вообще, позже.

#include <stdint.h>

// rem, quot ordering takes one extra instruction
struct divmod { uint64_t quotient, remainder; }
 div_by_100(uint64_t x) {
    struct divmod retval = { x%100, x/100 };
    return retval;
}

компилируется в (gcc 5.3 -O3 -mtune=haswell):

    movabs  rdx, 2951479051793528259
    mov     rax, rdi            ; Function arg starts in RDI (SysV ABI)
    shr     rax, 2
    mul     rdx
    shr     rdx, 2
    lea     rax, [rdx+rdx*4]    ; multiply by 5
    lea     rax, [rax+rax*4]    ; multiply by another 5
    sal     rax, 2              ; imul rax, rdx, 100 is better here (Intel SnB).
    sub     rdi, rax
    mov     rax, rdi
    ret
; return values in rdx:rax

используйте опцию "binary", чтобы увидеть константу в hex, так как выход дизассемблера делает это таким образом, в отличие от выхода источника asm gcc.

часть умножить на 100.

gcc использует вышеуказанную последовательность lea/lea / shl, такую же, как в вашем вопросе. Ваш ответ использует mov imm/mul последовательности.

ваши комментарии каждой версии они выбрали быстрее. Если так, то это из-за некоторых тонких выравнивание инструкций или другой вторичный эффект: на Intel SnB-family это столько же uops (3), и та же задержка критического пути (mov imm находится вне критического пути, и mul есть 3 цикла).

clang использует что я думаю это лучший вариант (imul rax, rdx, 100). Я подумал об этом прежде, чем увидел, что клэнг выбрал его, Хотя это не имеет значения. Это 1 плавленый домен uop (который может выполняться только на p0), все еще с задержкой 3c. Поэтому, если вы связаны с задержкой используя эту процедуру для мульти-точности, это, вероятно, не поможет, но это лучший выбор. (Если вы привязаны к задержке, вставка кода в цикл вместо передачи одного из параметров через память может сэкономить много циклов.)

imul работает, потому что вы используете только низкий 64b результата. Нет 2 или 3 операнд формы mul потому что низкая половина результата одинакова независимо от подписанной или неподписанной интерпретации входной.

кстати, с лязгом -march=native использует mulx для 64x64 - > 128, вместо mul, но ничего не выигрывает от этого. Согласно таблицам Agner Fog, это на один цикл хуже, чем mul.

AMD имеет хуже, чем задержка 3c для imul r,r,i (esp. версия 64b), возможно, поэтому gcc избегает ее. IDK сколько работы GCC сопровождающих положить в настройки затрат так Настройки, как -mtune=haswell работать хорошо, но много код не компилируется с -mtune настройка (даже подразумеваемого -march), поэтому я не удивлен, когда gcc делает выбор, который был оптимальным для старых процессоров или для AMD.

clang все еще использует imul r64, r64, imm С -mtune=bdver1 (бульдозер), что экономит m-ops, но при стоимости задержки 1c больше, чем при использовании lea/lea/shl. (lea со шкалой>1-задержка 2C на бульдозере).