В чем разница между различными уровнями оптимизации в gcc / g ++? - PullRequest
1 голос
/ 25 февраля 2020

Прежде чем кто-нибудь скажет мне посмотреть старые ответы или RTFM, пожалуйста, обратите внимание, что я уже сделал это, поэтому, пожалуйста, прочитайте детали, прежде чем направлять меня искать в другом месте.

Я установил, что Разница в уровнях оптимизации не так проста, как некоторые различные типы флагов оптимизации, которые были включены для более высокого уровня оптимизации.

Например, я впервые обнаружил разницу в флагах оптимизации O0 и O1, выполнив следующие действия :

gcc -c -Q -O1 --help=optimizers > /tmp/O1-opts
gcc -c -Q -O0 --help=optimizers > /tmp/O0-opts
diff /tmp/O0-opts /tmp/O1-opts | grep enabled

Это дало мне список различных флагов оптимизации, включенных O1 над O0.

Затем я скомпилировал код с -O0, но добавил все отдельные флаги оптимизации, включенные O1 более 0, потому что результат должен быть таким же, как O1, верно? Ну, угадайте что, это не так!

Итак, это доказывает, что разница между уровнями оптимизации заключается не просто в разных типах используемых флагов оптимизации. Я имею в виду, что помимо оптимизационных флагов, которые отображает gcc / g ++, должно быть больше различий в оптимизации.

Пожалуйста, дайте мне знать, если кто-то уже знает ответ на этот вопрос, или мне придется поискать исходный код g cc, который не будет для меня тривиальным. Спасибо!

Что касается причины, по которой я ищу эту информацию, у меня есть код AVX-512, в котором кэш L1D менее 3% пропускает с O0 или без флага оптимизации, но больше, чем 37% (хотя это ускоряет код) с O1 и выше. Если бы я мог понять, какой (скрытый) флаг вызывает это, я мог бы ускорить код еще дальше. В исходном коде g cc слишком много флагов в файле common.opt, поэтому я столкнулся со стеной.

1 Ответ

0 голосов
/ 25 февраля 2020

-O0 является особенным и подразумевает разлив / перезагрузку между каждым оператором для согласованной отладки: Почему clang создает неэффективный asm с -O0 (для этой простой суммы с плавающей запятой)? - Делает то, что вы ' Вы видите, что при ручном добавлении некоторые флаги оптимизации совпадают так: vars все еще сохраняются / перезагружаются вроде volatile?

Я предполагаю, что да, поскольку вы подтвердили предположение @ bg2b о избыточных доступах и отчете Абсолютное количество пропусков L1D не сильно меняется от O0 до O1. Теперь я понимаю, почему этот процент кажется завышенным.

Так что, похоже, что ни один из отдельных вариантов оптимизации -f... не контролирует такое специальное поведение -O0, и вам действительно придется использовать -O1 или -Og в качестве основы для настройки других параметров. (Например, -fno-..., пока вы не вернетесь к набору параметров, по умолчанию -O0.)

Параметры также отображаются в комментариях G CC с выводом -S -fverbose-asm -o-.


Кроме того, более медленная работа (из-за сохранения / перезагрузки или по любой другой причине) дает HW предварительную выборку большего времени для поддержки и подготовки данных в L2 или даже L1d до загрузки. выполняется и имеет промах требования.

...