Чому GCC використовує множення на дивне число при здійсненні цілого поділу?

Я читав про divі mulскладальних операціях, і я вирішив , щоб побачити їх у дії, написавши просту програму в C:

Розділення файлів.c

#include <stdlib.h>
#include <stdio.h>

int main()
{
    size_t i = 9;
    size_t j = i / 5;
    printf("%zu\n",j);
    return 0;
}

А потім генерувати код мови збірки за допомогою:

gcc -S division.c -O0 -masm=intel

Але дивлячись на згенерований division.sфайл, він не містить жодних діючих операцій! Натомість це робить якусь чорну магію зі зміщенням бітів та магічними числами. Ось фрагмент коду, який обчислює i/5:

mov     rax, QWORD PTR [rbp-16]   ; Move i (=9) to RAX
movabs  rdx, -3689348814741910323 ; Move some magic number to RDX (?)
mul     rdx                       ; Multiply 9 by magic number
mov     rax, rdx                  ; Take only the upper 64 bits of the result
shr     rax, 2                    ; Shift these bits 2 places to the right (?)
mov     QWORD PTR [rbp-8], rax    ; Magically, RAX contains 9/5=1 now, 
                                  ; so we can assign it to j

Що тут відбувається? Чому GCC взагалі не використовує div? Як він генерує це магічне число і чому все працює?

Поділ цілих чисел - одна з найповільніших арифметичних операцій, яку можна виконувати на сучасному процесорі, із затримкою до десятків циклів і поганою пропускною здатністю. (Для x86 див. Таблиці інструкцій Agner Fog та посібник з мікроарха ).

Якщо ви знаєте дільник заздалегідь, ви можете уникнути поділу, замінивши його набір інших операцій (множення, додавання та зсуви), які мають рівноцінний ефект. Навіть якщо потрібно декілька операцій, це часто все-таки пробігається набагато швидше, ніж саме ціле ділення.

Реалізація /оператора С таким способом замість послідовності з декількома інструкціями, що стосується, divє лише способом GCC, що робить поділ на константи. Це не вимагає оптимізації для всіх операцій і нічого не змінює навіть для налагодження. ( Однак, якщо -Osвикористовувати невеликий розмір коду, GCC може використовуватись div.) Використання мультиплікативного зворотного замість ділення - це як використання leaзамість mulіadd

В результаті ви бачите divабо виходите лише idivу тому випадку, якщо дільник не відомий під час компіляції.

Інформацію про те, як компілятор генерує ці послідовності, а також код, який дозволяє вам генерувати їх для себе (майже напевно, непотрібний, якщо ви не працюєте з компілятором braindead ), див .

Ділення на 5 - це те саме, що множення на 1/5, що знову ж таки, як множення на 4/5 і зміщення праворуч на 2 біти. Зазначене значення знаходиться CCCCCCCCCCCCCCCDу шістнадцятковому значенні , яке є двійковим поданням 4/5, якщо його ставити після шістнадцяткової точки (тобто двійкове значення на чотири п'яті 0.110011001100повторюється - див. Нижче, чому). Я думаю, ви можете взяти це звідси! Ви можете перевірити арифметику з фіксованою точкою (хоча зверніть увагу, вона округлена до цілого числа в кінці.

Щодо того, чому множення швидше, ніж ділення, і коли дільник зафіксований, це швидший маршрут.

Дивіться Повторне множення, підручник для детального опису про те, як це працює, пояснюючи терміни з фіксованою точкою. Він показує, як працює алгоритм пошуку зворотного зв'язку та як обробляти підписані поділи та модулі.

Розглянемо хвилинку, чому 0.CCCCCCCC...(шістнадцятковий) або 0.110011001100...двійковий дорівнює 4/5. Розділіть двійкове представлення на 4 (змініть праворуч на 2 місця), і ми отримаємо, 0.001100110011...яким за допомогою тривіального огляду можна додати оригінал, щоб отримати 0.111111111111..., що, очевидно, дорівнює 1, той самий спосіб 0.9999999...у десятковій мірі дорівнює одиниці. Таким чином, ми знаємо , що x + x/4 = 1, таким чином 5x/4 = 1, x=4/5. Потім він представляється як CCCCCCCCCCCCDу шістнадцятковій частині для округлення (так як двійкова цифра поза останньою поданою була б а 1).

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

Зморшкою є те, що ми не можемо точно репрезентувати реципрок (якщо тільки ділення не було силою двох, але в такому випадку ми можемо просто просто перетворити поділ на невеликий зсув). Тому для забезпечення правильних відповідей ми повинні бути обережними, щоб помилка у взаємній відповіді не викликала помилок у нашому кінцевому результаті.

-3689348814741910323 - 0xCCCCCCCCCCCCCCCD, це значення трохи більше 4/5, виражене в 0,64 фіксованої точки.

Коли ми помножимо 64-бітове ціле число на 0,64 фіксованого числа, отримаємо результат 64,64. Ми усікаємо значення на 64-бітне ціле число (ефективно округлюючи його до нуля), а потім виконуємо подальший зсув, який ділиться на чотири і знову скорочується. Подивившись на рівень біта, зрозуміло, що ми можемо розглядати обидві усічення як єдине усічення.

Це однозначно дає нам принаймні наближення ділення на 5, але чи дає нам точну відповідь, правильно округлену до нуля?

Щоб отримати точну відповідь, помилка повинна бути достатньо малою, щоб відповідь не була перенесена через межу округлення.

Точна відповідь на поділ на 5 завжди матиме дробову частину 0, 1/5, 2/5, 3/5 або 4/5. Тому позитивна помилка менше 1/5 у множинні та зміщеному результаті ніколи не висуне результат через межу округлення.

Похибка в нашій постійній дорівнює (1/5) * 2 ^-64 . Значення i менше 2 ^64, тому похибка після множення менше 1/5. Після ділення на 4 похибка менше (1/5) * 2 ⁻² .

(1/5) * 2 ⁻² <1/5, тому відповідь завжди дорівнює точному поділу та округленню до нуля.

На жаль, це працює не для всіх дільників.

Якщо ми спробуємо представити 4/7 як 0,64 фіксовану точку з округленням від нуля, то в кінцевому підсумку з помилкою (6/7) * 2 ^-64 . Помноживши на значення i трохи менше 2 ^64, ми закінчуємо помилкою трохи менше 6/7, а після ділення на чотири, ми виявляємо помилку трохи менше 1,5 / 7, що більше 1/7.

Отже, щоб правильно поділити ділення на 7, нам потрібно помножити на 0,65 фіксовану точку. Ми можемо це здійснити, помноживши на нижчі 64 біти нашого фіксованого номера, потім додавши початкове число (це може переповнюватись у біт переносу), а потім робити обертання через перенесення.

Ось посилання на документ алгоритму, який створює значення та код, які я бачу з Visual Studio (у більшості випадків), і який я припускаю, що все ще використовується в GCC для поділу змінного цілого числа на постійне ціле число.

http://gmplib.org/~tege/divcnst-pldi94.pdf

У статті uword має N біт, udword має 2N біт, n = чисельник = дивіденд, d = знаменник = дільник, initially спочатку встановлюється на ceil (log2 (d)), shpre є попередньою зміною (використовується перед множенням ) = e = кількість кінцевих нульових бітів у d, шпост - післязсувний (використовується після множення), прецизія - точність = N - е = N - шпре. Мета - оптимізувати обчислення n / d за допомогою попереднього зсуву, множення та післязсуву.

Прокрутіть униз до рисунка 6.2, де визначено, як створюється множник udword (максимальний розмір N + 1 біт), але не чітко пояснює процес. Я поясню це нижче.

На рис. 4.2 та на рисунку 6.2 показано, як множник може бути зведений до N біт або менше множника для більшості дільників. Рівняння 4.5 пояснює, як отримана формула, яка використовується для обробки N + 1 бітних множників на рисунках 4.1 та 4.2.

У випадку із сучасними процесорами X86 та іншими процесорами час множення фіксовано, тому попереднє зсув не допомагає цим процесорам, але все одно допомагає зменшити множник з N + 1 біт на N біт. Я не знаю, чи GCC або Visual Studio усунули попередню зміну для цілей X86.

Повернення до малюнка 6.2. Чисельник (дивіденд) для mlow і mhigh може бути більшим, ніж удворд, лише коли знаменник (дільник)> 2 ^ (N-1) (коли ℓ == N => mlow = 2 ^ (2N)), в цьому випадку оптимізована заміна n / d - порівняння (якщо n> = d, q = 1, інакше q = 0), тому множник не генерується. Початкові значення mlow і mhigh становитимуть N + 1 біт, і два поділи udword / uword можна використовувати для отримання кожного значення N + 1 біт (mlow або mhigh). Використання X86 в 64-бітовому режимі як приклад:

; upper 8 bytes of dividend = 2^(ℓ) = (upper part of 2^(N+ℓ))
; lower 8 bytes of dividend for mlow  = 0
; lower 8 bytes of dividend for mhigh = 2^(N+ℓ-prec) = 2^(ℓ+shpre) = 2^(ℓ+e)
dividend  dq    2 dup(?)        ;16 byte dividend
divisor   dq    1 dup(?)        ; 8 byte divisor

; ...
        mov     rcx,divisor
        mov     rdx,0
        mov     rax,dividend+8     ;upper 8 bytes of dividend
        div     rcx                ;after div, rax == 1
        mov     rax,dividend       ;lower 8 bytes of dividend
        div     rcx
        mov     rdx,1              ;rdx:rax = N+1 bit value = 65 bit value

Ви можете перевірити це за допомогою GCC. Ви вже бачили, як j = i / 5 обробляється. Погляньте, як обробляється j = i / 7 (що має бути випадком множника N + 1 біт).

У більшості поточних процесорів множина має фіксований термін, тому попереднє зміна не потрібне. Для X86 кінцевий результат - це дві послідовності інструкцій для більшості дільників і п’ять послідовностей інструкцій для дільників типу 7 (для емуляції N + 1 бітного множника, як показано в рівнянні 4.5 та рисунку 4.2 файлу pdf). Приклад коду X86-64:

;       rax = dividend, rbx = 64 bit (or less) multiplier, rcx = post shift count
;       two instruction sequence for most divisors:

        mul     rbx                     ;rdx = upper 64 bits of product
        shr     rdx,cl                  ;rdx = quotient
;
;       five instruction sequence for divisors like 7
;       to emulate 65 bit multiplier (rbx = lower 64 bits of multiplier)

        mul     rbx                     ;rdx = upper 64 bits of product
        sub     rbx,rdx                 ;rbx -= rdx
        shr     rbx,1                   ;rbx >>= 1
        add     rdx,rbx                 ;rdx = upper 64 bits of corrected product
        shr     rdx,cl                  ;rdx = quotient
;       ...

Я відповім з дещо іншого кута: Тому що це дозволено робити.

C і C ++ визначаються на абстрактній машині. Компілятор перетворює цю програму з точки зору абстрактної машини на конкретну машину, слідуючи правилу ніби .

• Компілятору дозволено вносити будь-які зміни до тих пір, поки це не змінить спостережувану поведінку, як зазначено в абстрактній машині. Немає жодних обґрунтованих очікувань, що компілятор перетворить ваш код найбільш простим можливим способом (навіть коли багато програмістів на C припускають це). Зазвичай це робить це тому, що компілятор хоче оптимізувати продуктивність порівняно з прямолінійним підходом (як детально обговорюється в інших відповідях).
• Якщо за будь-яких обставин компілятор "оптимізує" правильну програму до чогось, що має іншу поведінку, що спостерігається, це помилка компілятора.
• Будь-яка не визначена поведінка в нашому коді (підписане ціле число переповнення є класичним прикладом) і цей договір недійсний.