Чи небезпечний рівень оптимізації -O3 у г ++?

Я чув з різних джерел (хоча в основному від мого колеги), що компіляція з рівнем оптимізації -O3в g ++ якось "небезпечна", і цього слід уникати взагалі, якщо не доведено, що це необхідно.

Це правда, і якщо так, то чому? Чи варто мені просто дотримуватися -O2?

У перші дні gcc (2,8 і т.д.) і в часи egcs, і redhat 2,96 -O3 іноді був досить баггі. Але це вже понад десятиліття тому, і -O3 не сильно відрізняється від інших рівнів оптимізації (у баггісті).

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

Як особиста примітка, я вже багато років працюю над виробничим програмним забезпеченням у фінансовому секторі з -O3 і досі не стикався з помилкою, якої б там не було, якби я використовував -O2.

За популярним попитом, ось додаток:

-O3 і особливо додаткові прапори, такі як -funroll-петлі (не ввімкнено -O3), іноді можуть призвести до генерування більше машинного коду. За певних обставин (наприклад, на процесорі з виключно невеликим кешем інструкцій L1) це може спричинити уповільнення через весь код, наприклад, якийсь внутрішній цикл тепер не вкладається в L1I. Як правило, gcc намагається не генерувати так багато коду, але оскільки він зазвичай оптимізує загальний випадок, це може статися. Варіанти, особливо схильні до цього (наприклад, розмотування циклу), як правило, не включаються до -O3 і відповідно позначаються на сторінці сторінки. Як таке, зазвичай, добре використовувати -O3 для генерування швидкого коду, і лише повернутися до -O2 або -Os (що намагається оптимізувати для розміру коду), коли це доречно (наприклад, коли профайлер вказує, що L1I не вистачає).

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

Ото, мабуть, слід бути обережним при використанні -Ofast, де зазначено:

-Ofast дозволяє всі -O3 оптимізації. Він також дозволяє оптимізувати, які не відповідають усім стандартам, що відповідають стандартам.

що змушує мене зробити висновок, що -O3 повинен повністю відповідати стандартам.

З мого дещо випроміненого досвіду, застосування -O3до цілої програми майже завжди робить її повільніше (по відношенню до -O2), оскільки вона вмикає агресивний цикл розгортання та вбудовування, що робить програму більше не вміщеною в кеш-інструкцію. Для великих програм це також може бути -O2відносно -Os!

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

-O3 варіант включає в себе більш дорогі оптимізації, такі як функція вбудовування, на додаток до всіх оптимізацій нижчих рівнів '-O2' та '-O1'. Рівень оптимізації '-O3' може збільшити швидкість отриманого виконуваного файлу, але також може збільшити його розмір. За деяких обставин, коли ці оптимізації не сприятливі, ця опція може насправді зробити програму повільнішою.

Так, O3 - баггір. Я розробник компілятора і виявив явні і очевидні помилки gcc, спричинені O3, що генерує помилкові інструкції щодо збирання SIMD під час створення власного програмного забезпечення. З того, що я бачив, більшість виробничих програм поставляється з O2, а це означає, що O3 буде отримувати менше уваги тестування wrt та виправлення помилок.

Подумайте про це так: O3 додає більше перетворень поверх O2, що додає більше перетворень поверх O1. Статистично кажучи, більше перетворень означає більше помилок. Це справедливо для будь-якого компілятора.

Нещодавно у мене виникла проблема використання оптимізації за допомогою g++. Проблема була пов'язана з карткою PCI, де регістри (для команд і даних) були репресовані адресою пам'яті. Мій драйвер відобразив фізичну адресу на вказівник у програмі та передав її для викликаного процесу, який працював з ним так:

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

Картка діяла не так, як очікувалося. Коли я побачив збірку я зрозумів , що компілятор написав тільки someCommand[ the last ]в pciMemory, минаючи всі попередні записи.

На закінчення: будьте точні та уважні з оптимізацією.