| |
| 2.42, User294 (ok), 15:24, 27/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 А это не они потом оглашают прерии воплями по поводу грабель которых больше ни у кого нет? :)
| | |
| |
| 3.52, Taliban (?), 10:47, 30/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs
| | |
|
|
| 1.2, Аноним (-), 00:58, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– | |
Новость ни о чём.
P.S. Ну пусть сделают ключ --please-use-inline-functions-even-with-dash-Os.
| | |
| |
| 2.43, Alex (??), 16:49, 27/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
-use-inlining-in-Os-for-mozilla-braindead-distmakers
Fixed.
| | |
|
| 1.4, FPGA (ok), 01:24, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Ха! Впервые вижу чтобы жаловались на скорость когда юзают -Os, просто смех!..
| | |
| 1.8, Аноним (-), 03:49, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
OMG. Классный довод, про кеш. Ну пусть попробуют -O3, -O2, -flto там. :)
Написать чтоль им об этом.:)
| | |
| |
| 2.26, iZEN (ok), 15:14, 26/06/2010 [^] [^^] [^^^] [ответить]
| +10 +/– |
 "120 миллионов точно знают, как играть в футбол, в отличие от тех 22-х на футбольном поле" ©
| | |
| |
| 3.48, Аноним (-), 10:44, 28/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )
| | |
|
|
| 1.9, Vladimir (??), 05:00, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Уважаемые участники
есть ли у кого-нибудь конкретные примеры программ, скомпилированными с GCC 4.5, но которые не могли после этого работать?
(У меня только два примера: emacs и dvisvgm, со вторым совсем глухо, для первого есть "обходной" манёвр).
Похоже разработчики mozilla открыли ещё одну новую "фичу" GCC серии 4.5
| | |
| |
| 2.17, Аноним (17), 09:50, 26/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > emacs
несколько месяцев собираю emacs из bzr (trunk) с помощью gcc45 + -flto + gold на freebsd. Не замечал никаких проблем в runtime'е.
| | |
| 2.32, Аноним (-), 16:52, 26/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
У меня qt-webkit, собранный gcc-4.5, приводит к краху Arora, qutim, и даже qt-creator при просмотре документации.
| | |
|
| 1.10, DFX (ok), 07:12, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 а собирать с "-Os -finline-functions" не катит ? или оно прямо-таки сопротивляется и забивает ?
жаль вот с gcc 4.5 куча софта в мире генты, когда с флагом -flto/-fwhopr, не связывается после сборки :(
без него, правда, только два вышенаписанных примера выделываются, и то несчастное брошенное чудо, вроде ksquirrel и openastromenace, что с 4.4 или 4.3 не собиралось.
| | |
| 1.11, Аноним (-), 07:35, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Друзья, кто-нибудь может разъяснить, почему в релизной сборке Мозиллой не используется -O3? И почему даже разработчик GCC посоветовал -O2?
Я кроме увеличения времени сборки (одноразового, к тому же) проблем не вижу. Наверное, я чего-то не понимаю?
| | |
| |
| |
| 3.18, Аноним (-), 09:54, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> при -O3 размер исполняемого кода получается больше.
не намного больше чем по сравнению с -funroll-loops. Скорее всего боятся -ftree-vectorize.
| | |
|
| 2.19, ws (ok), 10:22, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно,
с -02 - к работе замечаний нет, но по сравнению с -Os субъективно работает медленее, хотя должно наоборот.
ИМХО, объясняется это меньшим требованием к памяти (кеш цпу в том числе). Ведь скорость выполнения команд процессора сейчас увеличилось намного больше (особенно если кусок исполняемого кода сидит в кеше), чем скорость доступа к ячейки памяти по сравнению с предыдущими поколениями...
p/s: Тестировал года 1,5-2 назад на E6750, RAM 2G, HDD Hitachi 500G на текущем срезе генты.
| | |
| |
| |
| 4.33, ws (ok), 16:57, 26/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Пробовал на генту мир собирать с -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.
| | |
|
| 3.29, аноним (?), 16:15, 26/06/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>субъективно работает медленее, хотя должно наоборот
Субъективно своё знаете куда можете?
| | |
| |
| 4.37, ws (ok), 19:42, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>субъективно работает медленее, хотя должно наоборот
>
>Субъективно своё знаете куда можете?
Моя субъективность очень совпадает с реальностью Mozilla Team... :)
| | |
|
|
|
| 1.12, Аноним (-), 08:06, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>режим оптимизации по размеру исполняемого кода в ущерб скорости
Интересная опция. Какая же это оптимизация тогда? В чем она заключается? в падении скорости? :)
| | |
| |
| 2.14, Alen (??), 08:20, 26/06/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вот сразу видно, что человек писатель, а не читатель :)
| | |
| 2.15, anonymous (??), 08:23, 26/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Какая же это оптимизация тогда? В чем она заключается?
русским языком же написано: "оптимизация по размеру". оптимизируют не только скорость.
| | |
| 2.34, Zenitur (?), 17:01, 26/06/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Если все оптимизации убрать, то собираться будет быстро, а работать - медленно.
| | |
| 2.50, User294 (ok), 12:46, 28/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Интересная опция. Какая же это оптимизация тогда? В чем она заключается?
> в падении скорости? :)
Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. В случае реального процессора - как видим не все так просто: более компактный код имеет больше шансов целиком влезть в кеш, и невзирая на то что в сумме будет выполнено как бы больше инструкций (N раз отработает не только тело цикла но и переходы на начало оного и анализ условий), они будут подтянуты не из тормозной в плане латентности оперативы, а из резвого кеша и ... можно даже и выиграть, как видим. Лишь бы код в кеш лез. По факту - соотношение сил еще и определяется соотношением латентностей и бандвиза кеша и оперативы. Что наверняка доставляет авторам компилеров и просто тем кому надо тотальный максимум скорости любой ценой, т.к. все это еще и нихрена не константа и в камне не выбито :)
| | |
| |
| 3.54, PereresusNeVlezaetBuggy (ok), 13:42, 04/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
 В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.
| | |
| |
| 4.56, User294 (ok), 15:18, 07/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь.
| | |
|
|
|
| 1.22, Роман (??), 12:54, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>Представители Mozilla ответили, что сборка с опцией "-Os" производится, так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"
Нда... а почему ж тогда отошли от "исторических" традиций использования gcc 4.3?
Непоследовательно как-то...
| | |
| 1.23, Роман (??), 12:56, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2"
Если так, то это был исторический _баг_ в старых gcc, исправленный в 4.5. А они ещё жалуются.
| | |
| |
| 2.39, Sem (??), 01:57, 27/06/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Включите мозг наконец! Это не баг. Что включать в -Os, а что нет, это мнение разработчиков gcc. Для таких крупных проектов как Mozilla, разница в размере с -Os и -O2 может быть очень существенной. А вот то, что, похоже, -Os -finline-functions не срабатывает, это не хорошо, это гораздо больше похоже на баг.
Лучше бы PGO обсудили )
| | |
|
| 1.27, аноним (?), 16:13, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Это идиотизм, как и -Os в принципе - нужно это разве что для всякого embedded и никакой производительности не гарантирует и не должно.
| | |
| |
| 2.40, Sem (??), 02:15, 27/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Это идиотизм, как и -Os в принципе - нужно это разве что
>для всякого embedded и никакой производительности не гарантирует и не должно.
>
Идиотизм - это делать опальные заявления.
В идеале, это конечно так и есть, но когда у тебя проект больше чем на 7 млн. строк, то тут уж крутишься как получится.
| | |
|
| 1.30, аноним (?), 16:17, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Нормальным системам (FreeBSD как минимум) пофиг - там все собирается с теми флагами, которые я сказал, а не с тем что исторически сложилось у криворуких разработчиков.
| | |
| |
| 2.46, i (??), 10:23, 28/06/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
причем здесь вы и разработчики мозиллы? и когда это фрибсд стала нормальной/по сравнению с чем, системой?
| | |
| 2.51, User294 (ok), 21:43, 28/06/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Нормальным системам (FreeBSD как минимум) пофиг
В "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).
| | |
|
| 1.31, Имя123321 (?), 16:42, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии,
в чём же регрессия, если стало только лучше? с -Os стало меньше памяти, как и планировали
в Мозиле всё больше и больше вендо-маразма.
| | |
| |
| 2.44, Alex (??), 16:52, 27/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
>gcc is dead
>use clang\llvm - true free BSDL
your brain is dead. use calc - true helper for those without brain
| | |
|
| 1.45, Аноним (-), 05:22, 28/06/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> В итоге, проблема оказалась связана с прекращением в GCC 4.5 inline-развертывания кода в режиме "-Os", что и приводит к замедлению выполнения. В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии
Глупость какая-то несусветная, как я же это регрессия? Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
| | |
| |
| 2.47, const86 (ok), 10:24, 28/06/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если встраиваемая функция совсем маленькая, то может получиться и без общего увеличения кода.
| | |
| |
| 3.55, PereresusNeVlezaetBuggy (ok), 13:45, 04/07/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
>
>Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если
>встраиваемая функция совсем маленькая, то может получиться и без общего увеличения
>кода.
Более того, при встраивании оптимизация прогоняется по всей результирующей функции, и там могут вылезти очевидные лишь для компилятора закономерности, которые он тоже сможет сократить (например, убрав лишние проверки или присваивания).
| | |
|
|
| 1.53, Alex (??), 10:16, 03/07/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.
| | |
|
