Компіляція GNU / Linux з оптимізацією -O3

Кажуть, що компіляція інструментів GNU та ядра Linux з -O3опцією оптимізації gcc створить дивні та прикольні помилки. Це правда? Хтось пробував це чи це просто підступ?

Він використовується в Gentoo, і я не помітив нічого незвичайного.

-O3 має ряд недоліків:

1. Перш за все, він часто виробляє повільніший код, ніж -O2або -Os. Іноді він створює довший код через розгортання циклу, що може бути насправді повільніше через гіршу продуктивність коду в кеші.
2. Як говорилося, іноді виробляється неправильний код. Це може бути або через помилку оптимізації або помилку в коді (наприклад, ігнорування суворого псевдоніму). Оскільки код ядра іноді є, а іноді доводиться бути «розумним», я б сказав, що можливо, якийсь розробник ядра допустив помилку. У мене виникли різні дивні проблеми, як, наприклад, збій утиліти простору користувачів, коли я компілював ядро ​​з gcc 4.5, яке на той момент було стабільним. Я все ще використовую gcc 4.4 для ядра та декількох вибраних утиліт для простору користувачів через різні помилки. Те саме може стосуватися і -O3.
3. Я не думаю, що це дає велику користь для ядра Linux. Ядро не робить великих обчислень і в місцях, де це робиться, воно оптимізоване при складанні. -O3прапор не змінить вартість перемикання контексту або швидкість вводу / виводу. Я не думаю, що щось на кшталт <0,1% прискорення загальної продуктивності того не варте.

Зауважте, що великі фрагменти ланцюжка інструментів (зокрема glibc) не збиваються, якщо ви змінюєте рівні оптимізації. Система збирання налаштована ігнорувати ваші налаштування -O для цих розділів у більшості розумних дистрибутивів.

Простіше кажучи, певні основні функції бібліотеки та ОС залежать від коду, який насправді виконує те, що він говорить, а не того, що було б швидше у багатьох випадках. зокрема -fgcse після перезавантаження (увімкнено -O3) може спричинити незвичайні проблеми.

Протягом останніх 10 років я працював у декількох системах Gentoo з 1000+ пакунками, що використовуються в -O3 -march=nativeусьому світі, і досі не стикався з жодним із цих міфічних проблем, пов'язаних із стабільністю -O3. Орієнтовні показники процесів, що інтенсивно працюють з процесором (наприклад, математичні / наукові програми), постійно показують, що -O3вони створюють швидший код, адже це було б безглуздо, якби не. Для більшості настільних програм так CFLAGSчи інакше не важливо, оскільки вони пов'язані з IO, але це дуже важливо для серверних матеріалів, які пов'язані з процесором.

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

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

Подумайте: чи варто 5% підсилення продуктивності підсистем Raid та ext3 або збоїв системи або потенційних втрат даних та / або корупції?

Налаштуйте всі ручки, щоб хотіти, щоб той порт Quake, який ви граєте, або аудіо / відео кодеки, які ви використовуєте для копіювання колекції DVD для файлів divx. Ви, ймовірно, побачите покращення. Просто не возиться з ядром, якщо у вас немає часу на марнотратство та дані, які ви можете втратити.