Чому GCC не оптимізує a * a * a * a * a * a to (a * a * a) * (a * a * a)?

Я роблю деяку числову оптимізацію на науковому застосуванні. Одне, що я помітив, - це те, що GCC оптимізує виклик pow(a,2), компілюючи його a*a, але виклик pow(a,6)не оптимізований і фактично викликає функцію бібліотеки pow, що значно уповільнює продуктивність. (На відміну від цього, компілятор Intel C ++ , який виконується icc, усуне виклик бібліотеки pow(a,6).)

Мені цікаво те, що коли я замінив pow(a,6)на a*a*a*a*a*aвикористання GCC 4.5.1 та параметрів " -O3 -lm -funroll-loops -msse4", він використовує 5 mulsdінструкцій:

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13

в той час, як я напишу (a*a*a)*(a*a*a), це виробить

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm13, %xmm13

що зменшує кількість інструкцій множення до 3. iccмає подібну поведінку.

Чому компілятори не розпізнають цей фокус оптимізації?

Тому що математика з плаваючою точкою не асоціативна . Спосіб групування операндів при множенні плаваючої крапки впливає на числову точність відповіді.

Як результат, більшість компіляторів дуже консервативно ставляться до упорядкування обчислень з плаваючою комою, якщо тільки вони не можуть бути впевнені, що відповідь залишиться такою ж, або якщо ви не скажете їм, що вам не важливо числової точності. Наприклад: варіант МКІ , який дозволяє куб.см до реассоцііруют операції з плаваючою точкою, або навіть варіант , який дозволяє навіть більш агресивні компроміси точності в відношенні швидкості.-fassociative-math-ffast-math

Лембдагек правильно вказує, що оскільки асоціативність не відповідає для чисел з плаваючою комою, "оптимізація"a*a*a*a*a*aдо(a*a*a)*(a*a*a)може змінити значення. Ось чому це заборонено C99 (якщо спеціально дозволено користувачем, через прапор компілятора або прагму). Як правило, припущення полягає в тому, що програміст написав те, що вона зробила з причини, і компілятор повинен це поважати. Якщо хочете(a*a*a)*(a*a*a), напишіть це.

Але це може бути болем писати; чому компілятор не може просто зробити [те, що ви вважаєте] правильним при використанні pow(a,6)? Тому що це було б неправильно робити. На платформі з хорошою математичною бібліотекою pow(a,6)значно точніше, ніж будь-яка a*a*a*a*a*aабо (a*a*a)*(a*a*a). Просто для надання деяких даних я провела невеликий експеримент на своєму Mac Pro, вимірюючи найгіршу помилку при оцінці ^ 6 для всіх одноточних плаваючих чисел між [1,2):

worst relative error using    powf(a, 6.f): 5.96e-08
worst relative error using (a*a*a)*(a*a*a): 2.94e-07
worst relative error using     a*a*a*a*a*a: 2.58e-07

Використання powзамість дерева множення зменшує помилку, пов'язану з коефіцієнтом 4 . Компілятори не повинні (і, як правило, не робити) "оптимізацій", що збільшують помилки, якщо тільки ліцензія на це не буде виконана користувачем (наприклад, через -ffast-math).

Зауважте, що GCC __builtin_powi(x,n)є альтернативою pow( ), яка повинна генерувати дерево вбудованого множення. Використовуйте це, якщо ви хочете торгувати точністю для продуктивності, але не хочете включати швидку математику.

Ще один подібний випадок: більшість компіляторів не оптимізується a + b + c + dдо (a + b) + (c + d)(це оптимізація, оскільки другий вираз можна конвертувати краще) і оцінює його як задане (тобто як (((a + b) + c) + d)). Це теж через кутові корпуси:

float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));

Це виводить 1.000000e-05 0.000000e+00

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

Деякі роки тому я намагався зробити зручніше оптимально обчислювати цілі сили, і придумав наступне. Це C ++, а не C, і все ще залежить від того, як компілятор буде дещо розумним щодо оптимізації / вбудовування речей. У будь-якому випадку, сподіваємось, вам це стане в нагоді на практиці:

template<unsigned N> struct power_impl;

template<unsigned N> struct power_impl {
    template<typename T>
    static T calc(const T &x) {
        if (N%2 == 0)
            return power_impl<N/2>::calc(x*x);
        else if (N%3 == 0)
            return power_impl<N/3>::calc(x*x*x);
        return power_impl<N-1>::calc(x)*x;
    }
};

template<> struct power_impl<0> {
    template<typename T>
    static T calc(const T &) { return 1; }
};

template<unsigned N, typename T>
inline T power(const T &x) {
    return power_impl<N>::calc(x);
}

_{Пояснення для допитливих: це не знаходить оптимального способу для обчислення повноважень, але оскільки пошук оптимального рішення є повною проблемою для NP, і це варто робити лише для невеликих потужностей у будь-якому випадку (на відміну від використання pow), немає причин для метушні. з деталлю.}

Тоді просто використовуйте його як power<6>(a).

Це полегшує набір повноважень (не потрібно писати 6 a набір с за допомогою паролів), і дозволяє вам здійснити подібну оптимізацію без -ffast-mathвипадків, коли у вас є залежність від точності, наприклад, компенсована сумація (приклад, коли порядок операцій є важливим) .

Ви, ймовірно, також можете забути, що це C ++ і просто використовувати його в програмі C (якщо він компілюється з компілятором C ++).

Сподіваюся, це може бути корисним.

Редагувати:

Ось що я отримую від свого компілятора:

для a*a*a*a*a*a,

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0

для (a*a*a)*(a*a*a),

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm0, %xmm0

для power<6>(a),

    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm0, %xmm1

GCC на насправді оптимізації a*a*a*a*a*aдля , (a*a*a)*(a*a*a)коли ціле. Я спробував за допомогою цієї команди:

$ echo 'int f(int x) { return x*x*x*x*x*x; }' | gcc -o - -O2 -S -masm=intel -x c -

Є багато прапорів gcc, але нічого фантазійного. Вони означають: Прочитати з stdin; використовувати рівень оптимізації O2; вивести лістинг мови складання замість двійкового; в списку повинен використовуватися синтаксис мови збірки Intel; вхід є мовою C (зазвичай мова походить із розширення вхідного файлу, але розширення файлу при читанні з stdin немає); і написати в stdout.

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

; x is in edi to begin with.  eax will be used as a temporary register.
mov  eax, edi  ; temp = x
imul eax, edi  ; temp = x * temp
imul eax, edi  ; temp = x * temp
imul eax, eax  ; temp = temp * temp

Я використовую систему GCC на Linux Mint 16 Petra, похідне Ubuntu. Ось версія gcc:

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

Як зазначали інші афіші, цей варіант не можливий у плаваючій точці, оскільки арифметика з плаваючою комою не асоціативна.

Тому що 32-бітове число з плаваючою комою - наприклад, 1.024 - не є 1.024. У комп’ютері 1.024 - це інтервал: від (1.024-e) до (1.024 + e), де "e" являє собою помилку. Деякі люди не усвідомлюють цього, а також вважають, що * в а * - це множення довільних точних чисел, без будь-яких помилок, прикріплених до цих чисел. Причина, чому деякі люди не усвідомлюють це, можливо, це математичні обчислення, які вони здійснювали в початкових школах: працюючи лише з ідеальними числами без прикріплених помилок і вважаючи, що добре просто ігнорувати "е", виконуючи множення. Вони не бачать "e", неявного в "float a = 1,2", "a * a * a" та подібних кодах C.

Якщо більшість програмістів визнають (і зможуть виконати) думку, що вираз C * a * a * a * a * a * a насправді не працює з ідеальними числами, тоді компілятор GCC буде БЕЗКОШТОВНИМ для оптимізації "a * a" * a * a * a * a "в кажуть" t = (a * a); t * t * t ", що вимагає меншої кількості множень. Але, на жаль, компілятор GCC не знає, чи вважає програміст, який пише код, що "a" - це число з помилкою або без неї. І так GCC буде робити лише те, що виглядає вихідний код - адже саме так GCC бачить «неозброєним оком».

... як тільки ви дізнаєтеся, який ви програміст , ви можете скористатися перемикачем "-Fast-math", щоб сказати GCC, що "Ей, GCC, я знаю, що я роблю!". Це дозволить GCC конвертувати a * a * a * a * a * a в інший фрагмент тексту - він виглядає відмінним від a * a * a * a * a * a - але все ж обчислює число в інтервалі помилок a * a * a * a * a * a. Це нормально, оскільки ви вже знаєте, що працюєте з інтервалами, а не ідеальними числами.

Жоден плакат ще не згадав про стискання плаваючих виразів (стандарт ISO C, 6.5p8 та 7.12.2). Якщо для FP_CONTRACTпрагми встановлено значення ON, компілятору дозволено розглядати такий вираз, як a*a*a*a*a*aодна операція, як би оцінюючи саме за допомогою одного округлення. Наприклад, компілятор може замінити його внутрішньою функцією живлення, яка є і швидшою, і більш точною. Це особливо цікаво, оскільки поведінка частково контролюється програмістом у вихідному коді, тоді як параметри компілятора, надані кінцевим користувачем, іноді можуть використовуватися неправильно.

Стан FP_CONTRACTпрагми за замовчуванням визначено реалізацією, так що компілятору дозволено робити такі оптимізації за замовчуванням. Таким чином, переносний код, який повинен чітко дотримуватися правил IEEE 754, повинен прямо встановити його OFF.

Якщо компілятор не підтримує цю прагму, він повинен бути консервативним, уникаючи такої оптимізації, якщо розробник вирішив її встановити OFF.

GCC не підтримує цю прагму, але, використовуючи параметри за замовчуванням, вона передбачає, що вона є ON; таким чином, для цілей з апаратним FMA, якщо потрібно запобігти перетворенню a*b+cна fma (a, b, c), потрібно надати такий варіант, як -ffp-contract=off(явно встановити прагму на OFF) або -std=c99(сказати GCC, щоб він відповідав деяким Стандартна версія C, тут C99, відповідно дотримуйтесь вищевказаного абзацу). Раніше останній варіант не перешкоджав трансформації, тобто GCC не відповідав цьому пункту: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845

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

Функції бібліотеки на зразок "pow" зазвичай ретельно розробляються, щоб отримати мінімально можливу помилку (у загальному випадку). Зазвичай це досягається наближенням функцій з сплайнами (згідно з коментарем Паскаля, як видається, найпоширенішою реалізацією є використання алгоритму Remez )

принципово наступна операція:

pow(x,y);

має властиву помилку приблизно такої ж величини, як і помилка в будь-якому одному множенні чи діленні .

Під час наступної операції:

float a=someValue;
float b=a*a*a*a*a*a;

має вроджену помилку, яка більше, ніж 5 разів більше помилки одного множення або ділення (тому що ви поєднуєте 5 множин).

Компілятор повинен бути дуже обережним щодо оптимізації, яку він робить:

1. якщо оптимізувати pow(a,6)для a*a*a*a*a*aнього може покращити продуктивність, але різко знизити точність чисел з плаваючою комою.
2. якщо оптимізувати a*a*a*a*a*a до pow(a,6)нього може насправді знизити точність, оскільки "a" було деяким спеціальним значенням, яке дозволяє множити без помилок (потужність 2 або деяке невелике ціле число)
3. якщо оптимізація pow(a,6)до (a*a*a)*(a*a*a)або (a*a)*(a*a)*(a*a)все ще може бути втратою точності порівняно з powфункцією.

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

Єдине, що має сенс (особиста думка та, мабуть, вибір у GCC без будь-якої конкретної оптимізації чи прапор компілятора) для оптимізації, має бути заміною "pow (a, 2)" на "a * a". Це було б єдине розумне, що повинен робити постачальник компіляторів.

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

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

Немає нічого поганого в наданні підказки компілятору, як ви робили тут. Це нормальна і очікувана частина процесу мікрооптимізації для перестановки висловлювань та виразів, щоб побачити, які відмінності вони принесуть.

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

На це питання вже є кілька хороших відповідей, але задля повноти я хотів би зазначити, що діючий розділ стандарту С є 5.1.2.2.3 / 15 (що таке саме, як розділ 1.9 / 9 у C ++ 11 стандарт). У цьому розділі зазначено, що оператори можуть бути перегруповані лише у тому випадку, якщо вони дійсно асоціативні чи комутативні.

gcc насправді може зробити цю оптимізацію навіть для чисел з плаваючою комою. Наприклад,

double foo(double a) {
  return a*a*a*a*a*a;
}

стає

foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret

з -O -funsafe-math-optimizations. Це впорядкування порушує IEEE-754, однак для цього потрібен прапор.

Цілі числа, що підписалися, як зазначив Пітер Кордес у коментарі, можуть зробити цю оптимізацію без цього -funsafe-math-optimizations як вона виконується саме тоді, коли переповнення немає і якщо є переповнення, ви отримуєте не визначену поведінку. Так ви отримуєте

foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret

з просто -O. Для непідписаних цілих чисел це ще простіше, оскільки вони працюють потужністю мод 2, і тому вони можуть бути перепорядковані вільно, навіть за умови переповнення.