Таблица уровней оптимизации компилятора GNU C ++ g ++, точная? - PullRequest
0 голосов
/ 04 марта 2019

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


Уровни оптимизации компилятора GNU C ++ g++

Ox      WHAT IS BEING OPTIMIZED                          EXEC  CODE  MEM  COMP
                                                         TIME  SIZE       TIME
------------------------------------------------------------------------------
O0      optimize for compilation time                   |   +    +    -    -
O1      optimize for code size and execution time #1    |   -    -    +    +
O2      optimize for code size and execution time #2    |   --   0    +    ++
O3      optimize for code size and execution time #3    |   ---  0    +    +++
Ofast   O3 with fast none accurate math calculations    |   ---  0    +    +++
Os      optimize for code size                          |   0    --   0    ++

+ увеличить ++ увеличить еще +++ увеличить еще больше-уменьшить - уменьшить еще --- уменьшить еще больше


Я использую версию 8.2, хотяэто должна быть общая таблица, взятая из здесь и переписанная в простой текст.

Мой вопрос: если это можно доверять, я не знаю этот веб-сайт,поэтому я лучше спросить профессионалов здесь.Итак, таблица более или менее точна?

1 Ответ

0 голосов
/ 04 марта 2019

Ваша таблица чрезвычайно точна.

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

Но нет гарантии, что -O3 оптимизация всегда дает код, которыйработает быстрее, чем тот же код, скомпилированный с -O2.Это обычно так, но не всегда.Вы можете найти патологический (или просто) странный исходный код C, который при компиляции с -O3 дает немного более медленный двоичный код, чем тот же исходный код C, скомпилированный с -O2.Например, -O3 может развернуть циклы"лучше", по крайней мере, "больше", чем -O2, но некоторый код может выполнить хуже , если в нем есть определенный циклболее развернут.Веб-сайт phoronix и другие тестируют GCC и наблюдают такое явление.

Имейте в виду, что оптимизация - это искусство, это в общем неразрешимая или неразрешимая проблема, а современные процессоры таксложность в том, что нет точной и полной модели их производительности (например, кэш, предсказатели ветвления, конвейер, неупорядоченное выполнение).Кроме того, подробная микроархитектура процессоров x86, очевидно, не является общедоступной (вы не можете получить VHDL или макет чипа Intel или AMD).Следовательно, опция -march= для GCC также имеет значение (один и тот же двоичный код не всегда хорош как для процессоров AMD и Intel, так и даже для процессоров Intel нескольких марок).Таким образом, если компилировать код на той же машине, на которой он запущен, рекомендуется передавать -march=native в дополнение к -O2 или -O3.

Люди, которым платят Intel и AMD, активно участвуют в GCC , но им не разрешено делиться всеми знаниями, которые они имеют внутри о чипах Intel или AMD.Им разрешено предоставлять (с лицензией GPLv3 + GCC) исходный код , который они вносят в компилятор GCC.Вероятно, инженеры AMD наблюдают за кодом GCC, предоставленным Intel, чтобы угадать микроархитектурные детали микросхем Intel, и наоборот.

И интересы Intel или AMD, очевидно, включают в себя обеспечение того, чтобы GCC хорошо работал со своими проприетарными чипами.То, что корпоративные интересы оправдывают оплату (как в Intel, так и в AMD) нескольких высококвалифицированных инженеров компиляторов, постоянно работающих над GCC.

На практике я заметил, что как AMD, так и инженеры Intel «играют в игру» с открытым исходным кодом.Они регулярно вносят код GCC, который также улучшает производительность их конкурентов.Это скорее социальный, этический и экономический вопрос, чем технический.

PS.Вы можете найти много статей и книг по экономике с открытым исходным кодом.

...