URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 68230
[ Назад ]

Исходное сообщение
"Разработчики Mozilla столкнулись с проблемой производительно..."

Отправлено opennews , 26-Июн-10 00:46 
Разработчики проекта 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
Новость: http://www.opennet.me/opennews/art.shtml?num=27104


Содержание

Сообщения в этом обсуждении
"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено qwerty44 , 26-Июн-10 00:46 
настоящие индейцы и так собирают firefox с -O3

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено User294 , 27-Июн-10 15:24 
А это не они потом оглашают прерии воплями по поводу грабель которых больше ни у кого нет? :)

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Taliban , 30-Июн-10 10:47 
в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 00:58 
Новость ни о чём.

P.S. Ну пусть сделают ключ --please-use-inline-functions-even-with-dash-Os.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Alex , 27-Июн-10 16:49 
-use-inlining-in-Os-for-mozilla-braindead-distmakers

Fixed.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено God , 28-Июн-10 11:32 
--God-please-make-may-program-very-fast

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено FPGA , 26-Июн-10 01:24 
Ха! Впервые вижу чтобы жаловались на скорость когда юзают -Os, просто смех!..

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Michael Shigorin random , 26-Июн-10 10:23 
"Ах, сколько нам открытий чудных"... ;)
Просто Вы ещё тоже многого не видели, довод про кэш справедлив.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 02:17 
Скажите им, чтобы попробовали clang

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 03:49 
OMG. Классный довод, про кеш. Ну пусть попробуют -O3, -O2, -flto там. :)
Написать чтоль им об этом.:)

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено iZEN , 26-Июн-10 15:14 
"120 миллионов точно знают, как играть в футбол, в отличие от тех 22-х на футбольном поле" ©

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 28-Июн-10 10:44 
Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Vladimir , 26-Июн-10 05:00 
Уважаемые участники

есть ли у кого-нибудь конкретные примеры программ, скомпилированными с GCC 4.5, но которые не могли после этого работать?

(У меня только два примера: emacs и dvisvgm, со вторым совсем глухо, для первого есть "обходной" манёвр).

Похоже разработчики mozilla открыли ещё одну новую "фичу" GCC серии 4.5


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 09:50 
> emacs

несколько месяцев собираю emacs из bzr (trunk) с помощью gcc45 + -flto + gold на freebsd. Не замечал никаких проблем в runtime'е.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Aquarius , 26-Июн-10 15:00 
такого рода "фич" полно в каждой ветке GCC

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено аноним , 26-Июн-10 16:14 
Нету, у меня все собирается gcc45, никаких проблем.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 16:52 
У меня qt-webkit, собранный gcc-4.5, приводит к краху Arora, qutim, и даже qt-creator при просмотре документации.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено DFX , 26-Июн-10 07:12 
а собирать с "-Os -finline-functions" не катит ? или оно прямо-таки сопротивляется и забивает ?

жаль вот с gcc 4.5 куча софта в мире генты, когда с флагом -flto/-fwhopr, не связывается после сборки :(
без него, правда, только два вышенаписанных примера выделываются, и то несчастное брошенное чудо, вроде ksquirrel и openastromenace, что с 4.4 или 4.3 не собиралось.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 07:35 
Друзья, кто-нибудь может разъяснить, почему в релизной сборке Мозиллой не используется -O3? И почему даже разработчик GCC посоветовал -O2?

Я кроме увеличения времени сборки (одноразового, к тому же) проблем не вижу. Наверное, я чего-то не понимаю?


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено anonymous , 26-Июн-10 08:39 
при -O3 размер исполняемого кода получается больше.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 09:54 
> при -O3 размер исполняемого кода получается больше.

не намного больше чем по сравнению с -funroll-loops. Скорее всего боятся -ftree-vectorize.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено ws , 26-Июн-10 10:22 
Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
с -02 - к работе замечаний нет, но по сравнению с -Os субъективно работает медленее, хотя должно наоборот.
ИМХО, объясняется это меньшим требованием к памяти (кеш цпу в том числе). Ведь скорость выполнения команд процессора сейчас увеличилось намного больше (особенно если кусок исполняемого кода сидит в кеше), чем скорость доступа к ячейки памяти по сравнению с предыдущими поколениями...

p/s: Тестировал года 1,5-2 назад на E6750, RAM 2G, HDD Hitachi 500G на текущем срезе генты.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено bircoph , 26-Июн-10 12:49 
> Пробовал на генту мир собирать с -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

У меня так три мира собрано, проблем нет.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено ws , 26-Июн-10 16:57 
>> Пробовал на генту мир собирать с -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 столкнулись с проблемой производительно..."
Отправлено аноним , 26-Июн-10 16:15 
>субъективно работает медленее, хотя должно наоборот

Субъективно своё знаете куда можете?


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено ws , 26-Июн-10 19:42 
>>субъективно работает медленее, хотя должно наоборот
>
>Субъективно своё знаете куда можете?

Моя субъективность очень совпадает с реальностью Mozilla Team...  :)


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 26-Июн-10 08:06 
>режим оптимизации по размеру исполняемого кода в ущерб скорости

Интересная опция. Какая же это оптимизация тогда? В чем она заключается? в падении скорости? :)


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Alen , 26-Июн-10 08:20 
Вот сразу видно, что человек писатель, а не читатель :)

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено anonymous , 26-Июн-10 08:23 
>Какая же это оптимизация тогда? В чем она заключается?

русским языком же написано: "оптимизация по размеру". оптимизируют не только скорость.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Zenitur , 26-Июн-10 17:01 
Если все оптимизации убрать, то собираться будет быстро, а работать - медленно.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено User294 , 28-Июн-10 12:46 
> Интересная опция. Какая же это оптимизация тогда? В чем она заключается?
> в падении скорости? :)

Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. В случае реального процессора - как видим не все так просто: более компактный код имеет больше шансов целиком влезть в кеш, и невзирая на то что в сумме будет выполнено как бы больше инструкций (N раз отработает не только тело цикла но и переходы на начало оного и анализ условий), они будут подтянуты не из тормозной в плане латентности оперативы, а из резвого кеша и ... можно даже и выиграть, как видим. Лишь бы код в кеш лез. По факту - соотношение сил еще и определяется соотношением латентностей и бандвиза кеша и оперативы. Что наверняка доставляет авторам компилеров и просто тем кому надо тотальный максимум скорости любой ценой, т.к. все это еще и нихрена не константа и в камне не выбито :)


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено PereresusNeVlezaetBuggy , 04-Июл-10 13:42 
В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено User294 , 07-Июл-10 15:18 
Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Роман , 26-Июн-10 12:54 
>Представители Mozilla ответили, что сборка с опцией "-Os" производится, так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"

Нда... а почему ж тогда отошли от "исторических" традиций использования gcc 4.3?
Непоследовательно как-то...


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Роман , 26-Июн-10 12:56 
>так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"

Если так, то это был исторический _баг_ в старых gcc, исправленный в 4.5. А они  ещё жалуются.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Sem , 27-Июн-10 01:57 
Включите мозг наконец! Это не баг. Что включать в -Os, а что нет, это мнение разработчиков gcc. Для таких крупных проектов как Mozilla, разница в размере с -Os и -O2 может быть очень существенной. А вот то, что, похоже, -Os -finline-functions не срабатывает, это не хорошо, это гораздо больше похоже на баг.

Лучше бы PGO обсудили )


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено аноним , 26-Июн-10 16:13 
Это идиотизм, как и -Os в принципе - нужно это разве что для всякого embedded и никакой производительности не гарантирует и не должно.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Sem , 27-Июн-10 02:15 
>Это идиотизм, как и -Os в принципе - нужно это разве что
>для всякого embedded и никакой производительности не гарантирует и не должно.
>

Идиотизм - это делать опальные заявления.
В идеале, это конечно так и есть, но когда у тебя проект больше чем на 7 млн. строк, то тут уж крутишься как получится.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено аноним , 26-Июн-10 16:17 
Нормальным системам (FreeBSD как минимум) пофиг - там все собирается с теми флагами, которые я сказал, а не с тем что исторически сложилось у криворуких разработчиков.

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено i , 28-Июн-10 10:23 
причем здесь вы и разработчики мозиллы? и когда это фрибсд стала нормальной/по сравнению с чем, системой?

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено User294 , 28-Июн-10 21:43 
> Нормальным системам (FreeBSD как минимум) пофиг

В "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Имя123321 , 26-Июн-10 16:42 
> В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии,

в чём же регрессия, если стало только лучше? с -Os стало меньше памяти, как и планировали

в Мозиле всё больше и больше вендо-маразма.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено kramer , 27-Июн-10 11:55 
gcc is dead
use clang\llvm - true free BSDL

"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Alex , 27-Июн-10 16:52 
>gcc is dead
>use clang\llvm - true free BSDL

your brain is dead. use calc - true helper for those without brain


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Аноним , 28-Июн-10 05:22 
> В итоге, проблема оказалась связана с прекращением в GCC 4.5 inline-развертывания кода в режиме "-Os", что и приводит к замедлению выполнения. В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии

Глупость какая-то несусветная, как я же это регрессия? Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено const86 , 28-Июн-10 10:24 
> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.

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


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено PereresusNeVlezaetBuggy , 04-Июл-10 13:45 
>> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
>
>Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если
>встраиваемая функция совсем маленькая, то может получиться и без общего увеличения
>кода.

Более того, при встраивании оптимизация прогоняется по всей результирующей функции, и там могут вылезти очевидные лишь для компилятора закономерности, которые он тоже сможет сократить (например, убрав лишние проверки или присваивания).


"Разработчики Mozilla столкнулись с проблемой производительно..."
Отправлено Alex , 03-Июл-10 10:16 
У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.