https://m.opennet.dev/openforum/vsluhforumID3/68230.html Разработчики проекта 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-разрядном варианте.<br><br><br>Убедиться в справедливости заявления может любой желающий, достаточно проверить скорость прохождения JavaScript-теста Sunspider, при сборке Firefox в GCC 4.5, тест показывает на 8% более низкие показатели при прочих равных условиях. Переход на GCC 4.5 был связан с плагинами и возможностью сборки с PGO (profile-guided optimization) . После обнаружения регрессии, разработчики Mozilla отменили свое решение о переходе на сборку с использованием GCC 4.5.<br><br><br>В ответ на заявление, один из разработчиков GCC подчеркнул (http://gcc.gnu.org/ml/gcc/2...<br><br>URL: http://www.pho https://m.opennet.dev/openforum/vsluhforumID3/68230.html#56 Wed, 07 Jul 2010 11:18:54 GMT Там еще стопицот факторов может быть, при том все из них оценить лично я для монстриков типа core i7 и подобных имхо даже обломаюсь. <br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#55 Sun, 04 Jul 2010 09:45:37 GMT &gt;&gt; Дублирование кода (встраивание inline) и уменьшение размера &#8212; это же полностью противоположные вещи.<br>&gt;<br>&gt;Не полностью. При встраивании экономится собственно вызов и сохранение/восстановление части регистров. Если <br>&gt;встраиваемая функция совсем маленькая, то может получиться и без общего увеличения <br>&gt;кода. <br><br>Более того, при встраивании оптимизация прогоняется по всей результирующей функции, и там могут вылезти очевидные лишь для компилятора закономерности, которые он тоже сможет сократить (например, убрав лишние проверки или присваивания).<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#54 Sun, 04 Jul 2010 09:42:35 GMT В реальных процессорах ещё хитрее: если длина цикла в микроинструкциях будет меньше, чем длина конвейера процессора, то мы будем иметь постоянную перезагрузку конвейера, и такой код будет работать _медленнее_.<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#53 Sat, 03 Jul 2010 06:16:38 GMT У мозиллы проблемы с производительностью в голове. От оперы и хрома отстает в 2 раза, тормозное и глючное, и GCC там не при чем.<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#52 Wed, 30 Jun 2010 06:47:55 GMT в принципе, разные числодробилки, компильнутые с этой опцией, работали корректно. единственное, в версиях 3-й ветки были какие-то проблемы с файловыми операциями из-за оптимизации. o_O fileopen происходил медленнее, чем последущая проверка поинтера. но это касалось сугубо nfs<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#51 Mon, 28 Jun 2010 17:43:14 GMT &gt; Нормальным системам (FreeBSD как минимум) пофиг <br><br>В "нормальной" системе для начала вообще GCC 4.5 не юзают. Как минимум сразу и по дефолту ;) (GPL v3 видите ли кому-то мешает).<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#50 Mon, 28 Jun 2010 08:46:37 GMT &gt; Интересная опция. Какая же это оптимизация тогда? В чем она заключается? <br>&gt; в падении скорости? :)<br><br>Как пример: есть цикл, где N раз делается нечто, допустим N заранее известно компилеру. Можно честно сгенерить код который отпедалит то что в цикле N раз. Будет относительно компактный код, честно изображающий конструкцию. А можно для скорости развернуть цикл, записав N раз код внутри цикла как развернутый, просто влобовую - N последовательностей действий. При этом, очевидно, есть экономия времени CPU - на прыжках в начало цикла и анализе его условий, коих в таком случае попросту нет, т.е. в сумме процессору придется смолотить на всю конструкцию меньше инструкций - PROFIT. Но код ессно выйдет жирнее, запись N раз одного и того же ведь, против записи 1 раз+цикл+анализ условий. В случае сферического процессора в вакууме, который всегда молотит с одинаковой скоростью - второй код получается значительно резвее первого, ну и собссно подобные по смыслу фокусы - считаются оптимизацией по скорости в ущерб размеру. https://m.opennet.dev/openforum/vsluhforumID3/68230.html#49 Mon, 28 Jun 2010 07:32:12 GMT --God-please-make-may-program-very-fast<br> https://m.opennet.dev/openforum/vsluhforumID3/68230.html#48 Mon, 28 Jun 2010 06:44:43 GMT Ну, про кэш может и реально, но не судьба с новой версией GCC попробовать и новые флаги.... Хотя, я не знаю, что у них там внутри команды... Может уже натешились с флагами досыта. ) Пойду, пособираю... )<br>