LINUX.ORG.RU
ФорумTalks

Гентушникам на заметку.

 , , , ,


1

1

Фороникс провёл серию тестов на эффективность различных уровней оптимизации на GCC 4.7.1. Собственно, сами уровни:

  • -O0 Сокращает время компиляции. Никаких оптимизаций не производится.
  • -O1 Базовая оптимизация. Компиляция занимает больше времени, большие функции занимают намного больше памяти.
  • -O2 Более глубокая оптимизация. Выпоняются почти все поддерживаемые оптимизации, за исключением особо «продвинутых». Увеличивается как время сборки, так и потребление памяти.
  • -O3 Оптимизация на грани экстрима. Включает в себя все оптимизационные ключи уровня -O2, плюс следующие: -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone.
  • -Os Оптимизация по размеру. Использует все ключи -O2, за исключением тех, что приводят к увеличению генерируемого кода: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version.
  • -Ofast Уровень наплевательства на стандарты :) Включает в себя всё из -O3, а также то, что порою не соответствует стандартам сборки/совместимости: -ffast-math и фортрано-специфические -fno-protect-parens and -fstack-arrays.

Тесты проводились на ubuntu 12.10 и AMD FX-8150 @ 3.6 ГГц

Больше - лучше 
               GraphicsMagick 1.3.12                                          Himeno 3.0       PostgreSQL

                blur           sharpen         resizing      HWB               PPS               TPC-B

-O0            64               41                 67           81                 240                 1596   

-O1            97               64                128          157                 410                1920

-O2            97                65               124          158                 589               2005

-O3           112               64                121          156                 676                1989

-Os           82                68                101          122                 540                1831

-Ofast       109               95                122         158                 705
Меньше - лучше
                  PHP 5.2.9               CRay 1.1          Smallpt 1.0      Open FMM Nero 2D

               time to compil             total time          rendering              total time

-O0               14.22                     76.23                116                      4514

-O1                22.10                     53.78                36                        613

-O2               29.85                    46.57                36                        530

-O3               32.71                     36.38                 32                       522

-Os                24.83                    72.89                51                        1066

-Ofast            32.91                     35.84                30                        510

ну как бы я и не сомневался, но за информацию - спасибо

Pinkbyte ★★★★★
()

Кстати, в Опере нормально таблички отображаются? а то у меня они распи разъехались.

Kindly_Cat
() автор топика

так какой вывод? Оставить все эти игры в оптимизации и положиться на мантейнеров?

JB ★★★★★
()
Ответ на: комментарий от JB

Это для мантейнеров таблички. А вывод такой: можно собирать с -О2 и -О3, посмотреть на стабильность, а на остальные опции забить.

abraziv_whiskey ★★★★★
()
Ответ на: комментарий от abraziv_whiskey

В большинстве случаев O2 либо выигрывает, либо приблизительно одинаково с O3. Вывод: O3 для простых смертных ненужно, юзать O2.

На работе: CFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe" (~x86, хотя поддержка EM64T имеется, проц старенький, да и на ОЗУ не богат)

Дома: CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe" (amd64, amdfam10 по сути)

leg0las ★★★★★
()
Ответ на: комментарий от ekzotech

Если ты не разработчик gcc, то все равно O2)

Я так понимаю Ofast тебе еще больше поломает то, что сломало O3 вместо O2.

leg0las ★★★★★
()
Ответ на: комментарий от ekzotech

Ну собери да посмотри, это же не проблема. Эти опции для тех, кто точно знает, зачем они им нужны.

abraziv_whiskey ★★★★★
()

По первой табличке -O0 выигрывает по скорости или это какие то другие показатели? Имеет смысл пересобрать ImageMagick и mysql/postgresql под -O0 ?

TDrive ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Цифры 64, 41, 67... напротив -O0 это, что? Я подумал, что это время работы blur, sharpen, resizing... на каком нибудь эталонном изображение.

TDrive ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Там написано «больше - лучше».

Это я уже понял.

Не важно что это.

Как не важно? Может эти условные единицы на практике абсолютно незначительны.

TDrive ★★★★★
()
Ответ на: комментарий от leg0las

O3 ничего не ломает, но в некоторых случаях даёт проигрыш по сравнению с O2 (как и показано в этом тесте).

x3al ★★★★★
()
Ответ на: комментарий от JB

Жаль, что к этому не приходят до получения пятой звезды.

ArtKun ★★★★★
()

Бульдозер для гентушников, с самого начала было понятно. Еще сравните gcc 4.5 march=k8 vs gcc 4.7 march=bdver1. Там прирост офигительный.

AlexVIP
()
Ответ на: комментарий от leg0las

O3 не включает ни одной небезопасной оптимизации (читать ман), но увеличивает объём кода. При забитом кэше получатся лишние тормоза, при свободном — выигрыш.

x3al ★★★★★
()
Ответ на: комментарий от JB

Оставить все эти игры в оптимизации и положиться на мантейнеров?

Иди на свой Дебайн или бубунточку и там ложись под них.

А меня никакими пирогами не заманишь на APT/Deb. Лучше тормозный Portage чем наркоманский APT.

PaxtonFettel
()
Ответ на: комментарий от x3al

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

leg0las ★★★★★
()
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от AlexVIP

На прирост от смены ГЦЦ и флагов посмотри.

Таки да, там был ключик, который выдавал огромную разницу.

ekzotech ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.