Опасен ли уровень оптимизации -O3 в g ++?

Я слышал из разных источников (хотя в основном от моего коллеги), что компиляция с уровнем оптимизации -O3в g ++ как-то «опасна», и ее следует избегать в целом, если в этом нет необходимости.

Это правда, и если да, то почему? Должен ли я просто придерживаться -O2?

В первые дни gcc (2.8 и т. Д.), А также во времена egcs и redhat 2.96-O3 иногда были довольно глючными. Но это более десяти лет назад, и -O3 мало чем отличается от других уровней оптимизации (в том, что касается ошибок).

Тем не менее, он, как правило, выявляет случаи, когда люди полагаются на неопределенное поведение, поскольку они более строго следуют правилам и особенно угловым случаям языка (ов).

Что касается меня, я уже много лет работаю с производственным программным обеспечением в финансовом секторе с -O3 и еще не столкнулся с ошибкой, которой бы не было, если бы я использовал -O2.

По многочисленным просьбам вот дополнение:

-O3 и особенно дополнительные флаги, такие как -funroll-loops (не включены -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 будет уделяться меньше внимания при тестировании и исправлении ошибок.

Подумайте об этом так: 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, минуя все предыдущие записи.

В заключение: будьте аккуратны и внимательны с оптимизацией.