LINUX.ORG.RU
Новости — GNU's Not Unix  

Снижение производительности при использовании GCC-4.5.0

 , , ,


0

0

14-го апреля этого года GNU выпустила GCC-4.5.0. И вот теперь стало известно, что при компиляции с ключом -Os (оптимизация по размеру исполняемого файла) полученный исполняемый файл работает гораздо медленнее, чем скомпилированный с теми же параметрами компилятором версии 4.3.

В списке рассылки разработчики GCC поясняют, что это связано с новой логикой разворачивания iniline-вставок при оптимизации -Os: теперь они разворачиваются только если это приведёт к уменьшению размера исполняемого файла (ревизии 158278 и 159931).

Изменения привели, например, к тому, что браузер FireFox при сборке GCC-4.5 теряет на различных тестах от 4 до 19 процентов производительности, причём и в 32, и в 64-битной сборке.

>>> Подробности

★★

Проверено: anonymous_incognito ()
Последнее исправление: name_no (всего исправлений: 1)

 ← 1 2 →

>FireFox вернётся

тоже incorrect, никогда релизные сборки не собирались чем-либо кроме

GCC: (GNU) 4.1.1 20061011 (Red Hat 4.1.1-30)

т.е. ни 4.3 ни 4.5 они не использовали, только старый 4.1, редхат

Sylvia ★★★★★
()

Желающие могут проверить это на JavaScript-тесте SunSpider, фороникс утверждает, что на нём производительность просела на 8%.

The only case where there wasn't a slowdown was with the 64-bit SunSpider JavaScript benchmark where it sped up by 8% when being built under GCC 4.5

Переводчики такие переводчики...

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

да уж, вообще новость скорее о том, что Мозилле стоит пересмотреть флаги сборки для ФФ, ссылочка на мои бенчмарки при разных типах сборки есть выше, +10% прироста производительности с -O2 и GCC 4.5.1pre по сравнению с официальной сборкой , ну и отпрофилировать его тоже могли бы, наверное не так уж много тех, кто использует ФФ на по-настоящему древних процессорах < Pentium2 (i686) и кешами L1 < 16 Kb, L2 < 256 Kb

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

> Переводчики такие переводчики

убрал ссылки на опеннет, спасибо, за уточнение

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

> да уж, вообще новость скорее о том, что Мозилле стоит пересмотреть флаги сборки для ФФ

если при одних и тех же параметрах получается более медленная программа, то виноваты не параметры.

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

> тоже incorrect,

поубирал. Больше не доверяю опеннету

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

ну в подробностях есть письмо в список рассылки, там достаточно внятно написано почему стоит исправить некоторые вещи с инлайнингом в С++ (о Си речи не идет)

Ну а раз уж форониксы решили пожевать это письмо в рассылку и привели примером ФФ, наверное стоит и сборщикам Мозиллы подумать о нормальных флагах? С другой стороны на форониксе пишут что (наконец!) хотят все же использовать PGO, с GCC 4.1.1 это невозможно, с 4.5.x это удобно (!),
c GCC 4.3 есть некоторые проблемы про сборке, но результат весьма неплох

Sylvia ★★★★★
()

>произсодительности

Может не будем писать желтые заголовки? Новость ни о чем.

tensai_cirno ★★★★★
()

Уже было. Порникс об этом во всю глотку орал.

helios ★★★★★
()

брррр - а кто-то кроме мозиллы (праильно назвались) использует -Os ? o_O

megabaks ★★★★
()

А по стандарту iniline вставки обязаны разворачиваться всегда или по желанию компилятора?

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

А по стандарту iniline вставки обязаны разворачиваться всегда или по желанию компилятора?

По желанию компилятора.

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

> > А по стандарту iniline вставки обязаны разворачиваться всегда или по желанию компилятора?

По желанию компилятора.


Ну тогда в чём претензии к GCC, если ему изначально было указано оптимизировать по размеру?

bbk123 ★★★★★
()

а что они хотели,этож оптимизация по размеру. только зачем она нужна?в чем профит? почему не сравнить с -О2 или -О3

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

в том, что до ревизии 158278 получался более быстрый бинарь, чем после.

Т.е. в том, что раньше гцц при указании оптимизировать по размеру больше уделял внимания производительности, чем размеру. Так что эта ревизия представляется вполне логичной.

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

> > в чём претензии к GCC

в том, что до ревизии 158278 получался более быстрый бинарь, чем после.


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

bbk123 ★★★★★
()

при оптимизации по размеру исполняемого файла, внезапно, файлы стали ещё меньше, но тормозить стало больше. новость то к чему?

RedPossum ★★★★★
()

нафига собирать с -Os? помоему с самого начала четвертой версии -Os заметно ухудшает производительность.. короче уже очень давно собираю все с -O2

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

Там в одном месте таблица — я раставил слеши

about:buildconfig

Build platform
target
i486-pc-linux-gnu

Build tools

Compiler / Version / Compiler flags

gcc / gcc version 4.3.2 (Debian 4.3.2-1.1) / -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -g -fno-strict-aliasing -pthread -pipe

c++ / gcc version 4.3.2 (Debian 4.3.2-1.1) / -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -g -fno-strict-aliasing -pthread -pipe

Configure arguments
--enable-application=xulrunner --prefix=/usr --with-default-mozilla-five-home=/usr/lib/xulrunner-1.9 --enable-default-toolkit=cairo-gtk2 --enable-pango --enable-xft --disable-freetype2 --enable-system-cairo --with-system-png --with-system-jpeg --with-system-zlib --with-system-bz2 --with-gssapi=/usr --with-system-nspr --with-system-nss --enable-xinerama --enable-single-profile --disable-profilesharing --enable-svg --enable-svg-renderer=cairo --enable-mathml --disable-pedantic --disable-long-long-warning --enable-gnomevfs --enable-gnomeui --disable-tests --disable-mochitest --disable-debug --enable-canvas --enable-js-binary --with-readline '--enable-extensions=default cookie permissions python/xpcom spellcheck' --disable-installer --disable-javaxpcom --disable-elf-dynstr-gc --enable-system-hunspell --disable-crashreporter --enable-system-sqlite --enable-system-lcms --disable-strip --disable-install-strip --enable-url-classifier --enable-startup-notification --host=i486-linux-gnu --build=i486-linux-gnu

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

> тоже incorrect, никогда релизные сборки не собирались чем-либо кроме


GCC: (GNU) 4.1.1 20061011 (Red Hat 4.1.1-30)

Ну если брать официальные сборки разработчиков, то да. А если брать FireFox, собранный сопроводителями дистрибутива, то нет.

В Убунте, например, FF собран gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5).

sjinks ★★★
()

после прочтения новости — проникся ещё большем отвращением к своей любимой мозилле :-(

(нет, нет, я конешно не удалю тебя, мозилла, настроение ты мне подиспортила)

# p.s.: если новость про -Os, то какого фига автор новости ничего не сказал про размер? хуже стало или нет?

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

-Os и более быстрый бинарь никак не связаны

Ulrich Drepper не согласен.

A larger code size means higher pressure on the L1i (and also L2 and higher level) caches. This can lead to less performance. Smaller code can be faster. Fortunately gcc has an optimization option to specify this. If -Os is used the compiler will optimize for code size. Optimizations which are known to increase the code size are disabled. Using this option often produces surprising results. Especially if the compiler cannot really take advantage of loop unrolling and inlining, this option is a big win.

Мотивируется это тем, что у кода, оптмизированного на размер, лучшая локальность и кэш L1i меньше забивается развернутыми функциями. Ну и чем меньше размер кода, тем больше вероятность того, что код будет находиться в кэше, в результате чего снижаются дорогостоящие операции чтения памяти и т.п.

PS — а на практике приходится сидеть с CacheGrind'ом и отлавливать места, где с кэшем все хреново.

sjinks ★★★
()

Насколько я понял, разработчики GCC исправили работу одной из опций компилятора, которая делает то, что ей и положено — минимизирует размер исполняемого файла. Из-за чего визг-то поднялся?

И автору новости на будущее: метку opensource в разделе GNU/FSF ставить неуместно.

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

>Из-за чего визг-то поднялся?

хомячки должны визжать

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

можно задавать размер кешей через

--param l1-cache-size=16 --param l2-cache-size=256

16k/256k

разумеется , у тех процессоров чей кеш будет меньше указанного будут проблемы с производительностью, поэтому стоит определиться с мейнстримом, я уже выше написала, наверное самые слабые x86 это Geode, i586 , не знаю какой там кеш, ну и посмотреть на P2-P3

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

если -O не указана ни в каком явном виде, подразумевается что она есть,
для отключения оптимизации стоит явно задавать -O0

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

PS — а на практике приходится сидеть с CacheGrind'ом и отлавливать места, где с кэшем все хреново.

Весьма глупое занятие: сейчас кэши различаются в разных процессорах до 24 раз (сравните Q9550 и Athlon Neo, например). При этом у них разная структура, скорость, ассоциативность и др., так что инструкции влазящие в кэш вашего компа могут не влезть у другого и наоборот где-то ваша оптимизация может быть избыточна.

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

>igher pressure on the L1i (and also L2 and higher level) caches.

Ох блин. Ну и какого хрена они тут эти пишут. Уже давно ясно, что сделать так, чтобы все помещалось в кеши процессора - не возможно. А оптимизация бывает 2х видов - по процессору и по памяти. Ну и соответственно в 1ой мы получаем код большего размера, но выполняющийся быстрее, т.к. развернуты циклы, стек оптимизирован и прочее, а во втором случае - получаем более медленный код, зато он не жрет память. О чем кипеж - не ясно. PS считаю, что те, кто поднял эту тему либо не компетентен, либо тонко троллит.

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

find ~/.mozilla/firefox -iname «*.sqlite» -exec sqlite3 {} «VACUUM; REINDEX;» \;


вот после такого он еще быстрее запускаться будет (только ФФ перед командой надо закрыть, а то базы попортит)


насчет суровости десктопа - если честно, надоело, раньше была kde4, ноутбук далеко не новый, много я все равно на нем не использую, поэтому мне хватает просто compiz + lxpanel, т.н. «свистелки» есть, но я предпочитаю их не запускать без лишней надобности,
на десктопе тоже принцип Оккама, все равно инет, музыку послушать, поиграть..

Sylvia ★★★★★
()

Заголовок новости некорректный. Желтизна какая-то.

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

> т.к. развернуты циклы, стек оптимизирован и прочее

Далеко не всегда. Обратите внимание, что сборка программы с -funroll-loops может дать худшие результаты. Ну и результат сборки с -O3 во многих случаях может оказаться медленнее, чем с -O2, в том числе и из-за агрессивного инлайнинга.

по процессору и по памяти

Еще и по скорости :-)

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

/tmp :$/usr/local/gcc-4.5/bin/cc -Q --help=optimizers |grep enabled > noparam
/tmp :$/usr/local/gcc-4.5/bin/cc -O0 -Q --help=optimizers |grep enabled > noopt
/tmp :$diff noopt noparam
/tmp :$


да, похоже с чем-то другим путаю, где-то -O подставляется по умолчанию...



кстати в -O0 не такой уж и ноль по оптимизации, что-то все равно остается
http://paste.org.ru/?2d7inr

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

> При этом у них разная структура, скорость, ассоциативность и др

Размер кэша и его параметры можно вычислять и в рантайме, было бы желание. Зная размер, ассоциативность и размер линии можно легко вычислить critical stride (что критично при операциях с большими массивами данных)

sjinks ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
GNU's Not Unix