форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

Сообщения по теме

[Сортировка по времени | RSS]

1. "Разработчики Mozilla столкнулись с проблемой производительно..."	+4 +/–
Сообщение от qwerty44 on 26-Июн-10, 00:46
настоящие индейцы и так собирают firefox с -O3
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	42. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от User294 (ok) on 27-Июн-10, 15:24
	А это не они потом оглашают прерии воплями по поводу грабель которых больше ни у кого нет? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Taliban on 30-Июн-10, 10:47
	в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Разработчики Mozilla столкнулись с проблемой производительно..."	+16 +/–
Сообщение от Аноним (??) on 26-Июн-10, 00:58
Новость ни о чём. P.S. Ну пусть сделают ключ --please-use-inline-functions-even-with-dash-Os.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Alex (??) on 27-Июн-10, 16:49
	-use-inlining-in-Os-for-mozilla-braindead-distmakers Fixed.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "Разработчики Mozilla столкнулись с проблемой производительно..."	+3 +/–
	Сообщение от God on 28-Июн-10, 11:32
	--God-please-make-may-program-very-fast
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Разработчики Mozilla столкнулись с проблемой производительно..."	+2 +/–
Сообщение от FPGA (ok) on 26-Июн-10, 01:24
Ха! Впервые вижу чтобы жаловались на скорость когда юзают -Os, просто смех!..
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

6. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от Аноним (??) on 26-Июн-10, 02:17
Скажите им, чтобы попробовали clang
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Разработчики Mozilla столкнулись с проблемой производительно..."	+2 +/–
Сообщение от Аноним (??) on 26-Июн-10, 03:49
OMG. Классный довод, про кеш. Ну пусть попробуют -O3, -O2, -flto там. :) Написать чтоль им об этом.:)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Разработчики Mozilla столкнулись с проблемой производительно..."	+10 +/–
	Сообщение от iZEN (ok) on 26-Июн-10, 15:14
	"120 миллионов точно знают, как играть в футбол, в отличие от тех 22-х на футбольном поле" ©
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	48. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Аноним (??) on 28-Июн-10, 10:44
	Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
Сообщение от Vladimir (??) on 26-Июн-10, 05:00
Уважаемые участники есть ли у кого-нибудь конкретные примеры программ, скомпилированными с GCC 4.5, но которые не могли после этого работать? (У меня только два примера: emacs и dvisvgm, со вторым совсем глухо, для первого есть "обходной" манёвр). Похоже разработчики mozilla открыли ещё одну новую "фичу" GCC серии 4.5
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от Аноним (??) on 26-Июн-10, 09:50
	> emacs несколько месяцев собираю emacs из bzr (trunk) с помощью gcc45 + -flto + gold на freebsd. Не замечал никаких проблем в runtime'е.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Aquarius (ok) on 26-Июн-10, 15:00
	такого рода "фич" полно в каждой ветке GCC
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от аноним on 26-Июн-10, 16:14
	Нету, у меня все собирается gcc45, никаких проблем.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от Аноним (??) on 26-Июн-10, 16:52
	У меня qt-webkit, собранный gcc-4.5, приводит к краху Arora, qutim, и даже qt-creator при просмотре документации.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Разработчики Mozilla столкнулись с проблемой производительно..."	+2 +/–
Сообщение от DFX (ok) on 26-Июн-10, 07:12
а собирать с "-Os -finline-functions" не катит ? или оно прямо-таки сопротивляется и забивает ? жаль вот с gcc 4.5 куча софта в мире генты, когда с флагом -flto/-fwhopr, не связывается после сборки :( без него, правда, только два вышенаписанных примера выделываются, и то несчастное брошенное чудо, вроде ksquirrel и openastromenace, что с 4.4 или 4.3 не собиралось.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от Аноним (??) on 26-Июн-10, 07:35
Друзья, кто-нибудь может разъяснить, почему в релизной сборке Мозиллой не используется -O3? И почему даже разработчик GCC посоветовал -O2? Я кроме увеличения времени сборки (одноразового, к тому же) проблем не вижу. Наверное, я чего-то не понимаю?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от anonymous (??) on 26-Июн-10, 08:39
	при -O3 размер исполняемого кода получается больше.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Аноним (??) on 26-Июн-10, 09:54
	> при -O3 размер исполняемого кода получается больше. не намного больше чем по сравнению с -funroll-loops. Скорее всего боятся -ftree-vectorize.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от ws (ok) on 26-Июн-10, 10:22
	Пробовал на генту мир собирать с -O3 - некоторые программы работают не стабильно, с -02 - к работе замечаний нет, но по сравнению с -Os субъективно работает медленее, хотя должно наоборот. ИМХО, объясняется это меньшим требованием к памяти (кеш цпу в том числе). Ведь скорость выполнения команд процессора сейчас увеличилось намного больше (особенно если кусок исполняемого кода сидит в кеше), чем скорость доступа к ячейки памяти по сравнению с предыдущими поколениями... p/s: Тестировал года 1,5-2 назад на E6750, RAM 2G, HDD Hitachi 500G на текущем срезе генты.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от bircoph on 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 У меня так три мира собрано, проблем нет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от ws (ok) on 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.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "Разработчики Mozilla столкнулись с проблемой производительно..."	–1 +/–
	Сообщение от аноним on 26-Июн-10, 16:15
	>субъективно работает медленее, хотя должно наоборот Субъективно своё знаете куда можете?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от ws (ok) on 26-Июн-10, 19:42
	>>субъективно работает медленее, хотя должно наоборот > >Субъективно своё знаете куда можете? Моя субъективность очень совпадает с реальностью Mozilla Team...  :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Разработчики Mozilla столкнулись с проблемой производительно..."	–1 +/–
Сообщение от Аноним (??) on 26-Июн-10, 08:06
>режим оптимизации по размеру исполняемого кода в ущерб скорости Интересная опция. Какая же это оптимизация тогда? В чем она заключается? в падении скорости? :)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Разработчики Mozilla столкнулись с проблемой производительно..."	+2 +/–
	Сообщение от Alen (??) on 26-Июн-10, 08:20
	Вот сразу видно, что человек писатель, а не читатель :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от anonymous (??) on 26-Июн-10, 08:23
	>Какая же это оптимизация тогда? В чем она заключается? русским языком же написано: "оптимизация по размеру". оптимизируют не только скорость.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "Разработчики Mozilla столкнулись с проблемой производительно..."	–1 +/–
	Сообщение от Zenitur on 26-Июн-10, 17:01
	Если все оптимизации убрать, то собираться будет быстро, а работать - медленно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	50. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от User294 (ok) on 28-Июн-10, 12:46
	> Интересная опция. Какая же это оптимизация тогда? В чем она заключается? > в падении скорости? :) Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. В случае реального процессора - как видим не все так просто: более компактный код имеет больше шансов целиком влезть в кеш, и невзирая на то что в сумме будет выполнено как бы больше инструкций (N раз отработает не только тело цикла но и переходы на начало оного и анализ условий), они будут подтянуты не из тормозной в плане латентности оперативы, а из резвого кеша и ... можно даже и выиграть, как видим. Лишь бы код в кеш лез. По факту - соотношение сил еще и определяется соотношением латентностей и бандвиза кеша и оперативы. Что наверняка доставляет авторам компилеров и просто тем кому надо тотальный максимум скорости любой ценой, т.к. все это еще и нихрена не константа и в камне не выбито :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	54. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 04-Июл-10, 13:42
	В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	56. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от User294 (ok) on 07-Июл-10, 15:18
	Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
Сообщение от Роман (??) on 26-Июн-10, 12:54
>Представители Mozilla ответили, что сборка с опцией "-Os" производится, так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2" Нда... а почему ж тогда отошли от "исторических" традиций использования gcc 4.3? Непоследовательно как-то...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от Роман (??) on 26-Июн-10, 12:56
>так как исторически сложилось, что такая сборка работает быстрее, чем при использовании "-O2" Если так, то это был исторический _баг_ в старых gcc, исправленный в 4.5. А они  ещё жалуются.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	39. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
	Сообщение от Sem (??) on 27-Июн-10, 01:57
	Включите мозг наконец! Это не баг. Что включать в -Os, а что нет, это мнение разработчиков gcc. Для таких крупных проектов как Mozilla, разница в размере с -Os и -O2 может быть очень существенной. А вот то, что, похоже, -Os -finline-functions не срабатывает, это не хорошо, это гораздо больше похоже на баг. Лучше бы PGO обсудили )
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Разработчики Mozilla столкнулись с проблемой производительно..."	–1 +/–
Сообщение от аноним on 26-Июн-10, 16:13
Это идиотизм, как и -Os в принципе - нужно это разве что для всякого embedded и никакой производительности не гарантирует и не должно.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	40. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Sem (??) on 27-Июн-10, 02:15
	>Это идиотизм, как и -Os в принципе - нужно это разве что >для всякого embedded и никакой производительности не гарантирует и не должно. > Идиотизм - это делать опальные заявления. В идеале, это конечно так и есть, но когда у тебя проект больше чем на 7 млн. строк, то тут уж крутишься как получится.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от аноним on 26-Июн-10, 16:17
Нормальным системам (FreeBSD как минимум) пофиг - там все собирается с теми флагами, которые я сказал, а не с тем что исторически сложилось у криворуких разработчиков.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	46. "Разработчики Mozilla столкнулись с проблемой производительно..."	+2 +/–
	Сообщение от i (??) on 28-Июн-10, 10:23
	причем здесь вы и разработчики мозиллы? и когда это фрибсд стала нормальной/по сравнению с чем, системой?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	51. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от User294 (ok) on 28-Июн-10, 21:43
	> Нормальным системам (FreeBSD как минимум) пофиг В "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от Имя123321 on 26-Июн-10, 16:42
> В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии, в чём же регрессия, если стало только лучше? с -Os стало меньше памяти, как и планировали в Мозиле всё больше и больше вендо-маразма.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Разработчики Mozilla столкнулись с проблемой производительно..."	+1 +/–
Сообщение от kramer (??) on 27-Июн-10, 11:55
gcc is dead use clang\llvm - true free BSDL
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	44. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от Alex (??) on 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
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
Сообщение от Аноним (??) on 28-Июн-10, 05:22
> В итоге, проблема оказалась связана с прекращением в GCC 4.5 inline-развертывания кода в режиме "-Os", что и приводит к замедлению выполнения. В настоящее время разработчики рассматривают возможные пути устранения возникшей регрессии Глупость какая-то несусветная, как я же это регрессия? Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	47. "Разработчики Mozilla столкнулись с проблемой производительно..."	+/–
	Сообщение от const86 (ok) on 28-Июн-10, 10:24
	> Дублирование кода (встраивание inline) и уменьшение размера — это же полностью противоположные вещи. Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если встраиваемая функция совсем маленькая, то может получиться и без общего увеличения кода.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

53. "Разработчики Mozilla столкнулись с проблемой производительно..."	–1 +/–
Сообщение от Alex (??) on 03-Июл-10, 10:16
У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема