Разработчики проекта Mozilla опубликовали (http://gcc.gnu.org/ml/gcc/2010-06/msg00715.html) уведомление, в котором приводятся факты значительного падения производительности Firefox при его сборке в GCC 4.5. Проблемы были обнаружены после попытки перехода для сборки Linux-версии браузера с GCC 4.3 на GCC 4.5, после чего автоматизированные тесты выявили падение производительности браузера на 4-19%, как в 32-разрядном, так и в 64-разрядном варианте.
Убедиться в справедливости заявления может любой желающий, достаточно проверить скорость прохождения JavaScript-теста Sunspider, при сборке Firefox в GCC 4.5, тест показывает на 8% более низкие показатели при прочих равных условиях. Переход на GCC 4.5 был связан с плагинами и возможностью сборки с PGO (profile-guided optimization) . После обнаружения регрессии, разработчики Mozilla отменили свое решение о переходе на сборку с использованием GCC 4.5.
В ответ на заявление, один из разработчиков GCC подчеркнул (http://gcc.gnu.org/ml/gcc/2...URL: http://www.phoronix.com/scan.php?page=news_item&px=ODM2NQ
Новость: https://www.opennet.ru/opennews/art.shtml?num=27104
настоящие индейцы и так собирают firefox с -O3
А это не они потом оглашают прерии воплями по поводу грабель которых больше ни у кого нет? :)
в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs
Новость ни о чём.P.S. Ну пусть сделают ключ --please-use-inline-functions-even-with-dash-Os.
-use-inlining-in-Os-for-mozilla-braindead-distmakersFixed.
--God-please-make-may-program-very-fast
Ха! Впервые вижу чтобы жаловались на скорость когда юзают -Os, просто смех!..
"Ах, сколько нам открытий чудных"... ;)
Просто Вы ещё тоже многого не видели, довод про кэш справедлив.
Скажите им, чтобы попробовали clang
OMG. Классный довод, про кеш. Ну пусть попробуют -O3, -O2, -flto там. :)
Написать чтоль им об этом.:)
"120 миллионов точно знают, как играть в футбол, в отличие от тех 22-х на футбольном поле" ©
Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )
Уважаемые участникиесть ли у кого-нибудь конкретные примеры программ, скомпилированными с GCC 4.5, но которые не могли после этого работать?
(У меня только два примера: emacs и dvisvgm, со вторым совсем глухо, для первого есть "обходной" манёвр).
Похоже разработчики mozilla открыли ещё одну новую "фичу" GCC серии 4.5
> emacsнесколько месяцев собираю emacs из bzr (trunk) с помощью gcc45 + -flto + gold на freebsd. Не замечал никаких проблем в runtime'е.
такого рода "фич" полно в каждой ветке GCC
Нету, у меня все собирается gcc45, никаких проблем.
У меня qt-webkit, собранный gcc-4.5, приводит к краху Arora, qutim, и даже qt-creator при просмотре документации.
а собирать с "-Os -finline-functions" не катит ? или оно прямо-таки сопротивляется и забивает ?жаль вот с gcc 4.5 куча софта в мире генты, когда с флагом -flto/-fwhopr, не связывается после сборки :(
без него, правда, только два вышенаписанных примера выделываются, и то несчастное брошенное чудо, вроде ksquirrel и openastromenace, что с 4.4 или 4.3 не собиралось.
Друзья, кто-нибудь может разъяснить, почему в релизной сборке Мозиллой не используется -O3? И почему даже разработчик GCC посоветовал -O2?Я кроме увеличения времени сборки (одноразового, к тому же) проблем не вижу. Наверное, я чего-то не понимаю?
при -O3 размер исполняемого кода получается больше.
> при -O3 размер исполняемого кода получается больше.не намного больше чем по сравнению с -funroll-loops. Скорее всего боятся -ftree-vectorize.
Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
с -02 - к работе замечаний нет, но по сравнению с -Os субъективно работает медленее, хотя должно наоборот.
ИМХО, объясняется это меньшим требованием к памяти (кеш цпу в том числе). Ведь скорость выполнения команд процессора сейчас увеличилось намного больше (особенно если кусок исполняемого кода сидит в кеше), чем скорость доступа к ячейки памяти по сравнению с предыдущими поколениями...p/s: Тестировал года 1,5-2 назад на E6750, RAM 2G, HDD Hitachi 500G на текущем срезе генты.
> Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
> с -02 - к работе замечаний нетx86, по-видимому?
Добавь -fno-tree-vectorize это известный баг gcc:
https://bugs.gentoo.org/show_bug.cgi?id=270120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156У меня так три мира собрано, проблем нет.
>> Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
>> с -02 - к работе замечаний нет
>
>x86, по-видимому?да
>Добавь -fno-tree-vectorize это известный баг gcc:
>https://bugs.gentoo.org/show_bug.cgi?id=270120
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156Возможно такого рода и был баг (я сильно не вникал в эту проблему), но я пробовал еще на 4.3 или даже 4.1 ветке (я пользуюсь стабильной веткой для toolchains).
Но я остановился на -Os. Т.к. главное в десктопном компе не быстродействие ЦПУ, а доступность большего объема памяти. А в итоге скорость работы с программами оказалась выше для -Os чем для -O2 или -O3.Вот мои опции ключики для gcc
CFLAGS="-pipe -march=core2 -Os -mfpmath=sse,387 -frename-registers -ftree-vectorize -finline-functions -Wno-error "
CXXFLAGS="${CFLAGS} -finline-limit=1000 -fpermissive"
LDFLAGS="-Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-O1"Кстати еще одно объяснение быстрого выполнения программ для -Os это время считывания ее с HDD.
>субъективно работает медленее, хотя должно наоборотСубъективно своё знаете куда можете?
>>субъективно работает медленее, хотя должно наоборот
>
>Субъективно своё знаете куда можете?Моя субъективность очень совпадает с реальностью Mozilla Team... :)
>режим оптимизации по размеру исполняемого кода в ущерб скоростиИнтересная опция. Какая же это оптимизация тогда? В чем она заключается? в падении скорости? :)
Вот сразу видно, что человек писатель, а не читатель :)
>Какая же это оптимизация тогда? В чем она заключается?русским языком же написано: "оптимизация по размеру". оптимизируют не только скорость.
Если все оптимизации убрать, то собираться будет быстро, а работать - медленно.
> Интересная опция. Какая же это оптимизация тогда? В чем она заключается?
> в падении скорости? :)Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. В случае реального процессора - как видим не все так просто: более компактный код имеет больше шансов целиком влезть в кеш, и невзирая на то что в сумме будет выполнено как бы больше инструкций (N раз отработает не только тело цикла но и переходы на начало оного и анализ условий), они будут подтянуты не из тормозной в плане латентности оперативы, а из резвого кеша и ... можно даже и выиграть, как видим. Лишь бы код в кеш лез. По факту - соотношение сил еще и определяется соотношением латентностей и бандвиза кеша и оперативы. Что наверняка доставляет авторам компилеров и просто тем кому надо тотальный максимум скорости любой ценой, т.к. все это еще и нихрена не константа и в камне не выбито :)
В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.
Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь.
>Представители Mozilla ответили, что сборка с опцией "-Os" производится, так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"Нда... а почему ж тогда отошли от "исторических" традиций использования gcc 4.3?
Непоследовательно как-то...
>так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"Если так, то это был исторический _баг_ в старых gcc, исправленный в 4.5. А они ещё жалуются.
Включите мозг наконец! Это не баг. Что включать в -Os, а что нет, это мнение разработчиков gcc. Для таких крупных проектов как Mozilla, разница в размере с -Os и -O2 может быть очень существенной. А вот то, что, похоже, -Os -finline-functions не срабатывает, это не хорошо, это гораздо больше похоже на баг.Лучше бы PGO обсудили )
Это идиотизм, как и -Os в принципе - нужно это разве что для всякого embedded и никакой производительности не гарантирует и не должно.
>Это идиотизм, как и -Os в принципе - нужно это разве что
>для всякого embedded и никакой производительности не гарантирует и не должно.
>Идиотизм - это делать опальные заявления.
В идеале, это конечно так и есть, но когда у тебя проект больше чем на 7 млн. строк, то тут уж крутишься как получится.
Нормальным системам (FreeBSD как минимум) пофиг - там все собирается с теми флагами, которые я сказал, а не с тем что исторически сложилось у криворуких разработчиков.
причем здесь вы и разработчики мозиллы? и когда это фрибсд стала нормальной/по сравнению с чем, системой?
> Нормальным системам (FreeBSD как минимум) пофигВ "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).
> В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии,в чём же регрессия, если стало только лучше? с -Os стало меньше памяти, как и планировали
в Мозиле всё больше и больше вендо-маразма.
gcc is dead
use clang\llvm - true free BSDL
>gcc is dead
>use clang\llvm - true free BSDLyour brain is dead. use calc - true helper for those without brain
> В итоге, проблема оказалась связана с прекращением в GCC 4.5 inline-развертывания кода в режиме "-Os", что и приводит к замедлению выполнения. В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессииГлупость какая-то несусветная, как я же это регрессия? Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если встраиваемая функция совсем маленькая, то может получиться и без общего увеличения кода.
>> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
>
>Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если
>встраиваемая функция совсем маленькая, то может получиться и без общего увеличения
>кода.Более того, при встраивании оптимизация прогоняется по всей результирующей функции, и там могут вылезти очевидные лишь для компилятора закономерности, которые он тоже сможет сократить (например, убрав лишние проверки или присваивания).
У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.