Компиляция 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-after-reload (включается -O3) может вызвать странные проблемы.

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

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

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

Подумайте об этом: стоит ли увеличение производительности подсистем raid и ext3 на 5%, сбои системы или потенциальная потеря данных и / или повреждение?

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