ZED 03.02.2011 03:35
Есть вопрос! — Есть ли сейчас смысл от Swiftfox?
В этом вопросе ключевое слово сейчас. Каких-то принципиально новых инструкций у процессоров, влияющих на производительность софта вроде не замечено (кроме AES у Intel SB). По ключу оптимизации -O4 ни в интернетах, ни в мане к gcc ничего не нашел. По сравнению с 64-битными сборками и вовсе отличий быть не должно. Я обоснованных причин использовать Swiftfox вместо оригинала пока не вижу. Однако......Swiftfox какой-то мутный. Скачал 64-битный бинарник с официального сайта, а 64 битами там и не пахнет:
readelf -a swiftfox-bin | head
Точно такой же вывод дает 32-битный бинарник с сайта мозилы. Бутафория? О_о
От 64-битной версии браузера скорость возрастает весьма ощутимо (ценой памяти), а они сборку даже не осилили. Может для слоупоков типа дебиана и убунты, собирающих до сих пор 32-битные версии под i386 польза какая-то и будет, а для всех остальных, давно осиливших i586/i686 в чем профит? К слову сказать дебиану нужна совместимость с железом, так что тут он чист, а вот негры обещали с 10.10 собирать под i586 и чота не видно. Ну а пользователи 64-битных систем выходит получат "оптимизированную" 32-битную версию?
Кругом как не почитаешь, везде однотипные тексты, стыренные друг у друга или с официального сайта, где шапка не меняется годами и кстати тухлый форум. И не одного аргумента. Вроде да кабы. Кому-то кажется что работает быстрее, а кому-то кажется что потребляет памяти на пару мегабайт меньше. Мне лично кажется что это какой то развод. Если бы один ключ -O4 у gcc творил такие чудеса, с ним бы конпеляли и конпеляли, а его даже в мане нету.
Ну и напоследок все же решил померять письки и вышло даже забавно. Мерял в дебиане под виртуалкой iceweasel (i386) против swiftfox (prescott), который отметился как firefox. Добрые люди все таки затерли ссылку, ниже исходный скрин:
И хотя я в браузере не бенчмарки меряю, а работаю, на разницу в быстродействии мне было бы интересно взглянуть, если она хотя бы отличалась от статистической погрешности и хотя бы в обратную сторону. Я допускаю что виртуальная машина дала долю погрешности, но я не верю что i386 работает быстрее i686 (а prescott позиционируется еще более оптимизированным), если последний конечно правильно скомпилирован. Пока я ничего выдающегося не вижу. Я вижу словоблудие и эффект плацебо. Но может у вас другое мнение?
wiz 03.02.2011 09:18 #
+ 4 -
«говносборки ненужны» © народ
Поддерживаю. Но тут не сборка, а те же исходники, якобы скомпилированные с оптимизацией под современные процессоры. С таким успехом и 64 битные версии можно назвать говносборками. Фокус в том что оптимизация походу липовая оказалась.
Ну, в своё время проект вроде был актуален. Я даже ставил на пару месяцев. А сейчас как-то уже подустарел. 4.х и так шустрый (по слухам), а для конкретных скоростедротов есть другие браузеры.
Если бы один ключ -O4 у gcc творил такие чудеса, с ним бы конпеляли и конпеляли, а его даже в мане нету.
Со времен gcc версии 2 есть еще -O6, не заморачивайтесь так сильно оптимизацией ;)
Не так важно что есть в теории, сколько то, что используют на практике. Я не гентушник, но пишут что больше -O3 смысла нет использовать.
дело не только в параметере O. gcc может компилировать под конкретный проц, например core2, а не только i686.
конечно да. но системного 200% прироста не будет. какие-то функции конечно прибавят, но другие могут и затормозить наоборот
давно осиливших i586/i686 в чем профит?
Pentium Pro и первое поколение MMX - это круто.
Полностью согласен.
И щдаже дело не в том, что оказалось оптимизации там нет никакой. Дело в универсальности. Если требуется создать бинарник, который поддерживается большинством железа, оптимизация на скорость и размер по умолчанию идёт лесом. Там вверху правильно заметили. Есть Gentoo. И фишка Gentoo как раз в том, что я мало того, что на своей системе собираю всё под один определённый проц, выкинув ненужные мне компоненты. За счёт этого и скорость. Но этот мой бинарник, собранный под двухядерный Athlon XP, не заработает на любой 32-битной системе и будет глючить на большинстве 64-битных. Зато у меня летает.
Если же стоит цель собрать пакет, который должен запустить на всём чём угодно, начиная от древних пентиумов и заканчивая какими-нибудь квадами, ни о какой оптимизации речи и быть не может.
Ну а что касается ключа -О, это уже давно размусоленная тема. Выше -О2 для стабильного пакета использовать не стоит, если не знаешь, ччто конкретно делаешь. Высокие уровни оптимизации завязаны на экспериментальные и/или нестабильные фишки компилятора. Те фишки, что в процеессе разработки хорошо себя зарекомендуют, со временем переносятся в -О2. Существуют, конечно, случаи, когда использование более высокого уровня оптимизации gcc полезно. Но чтобы это узнать, надо быть программистом, хорошо разбираться в самих фишках оптимизации и знать исходник компилируемой программы, чтобы быть уверенным в надёжности использованных в процессе написания функций.
И щдаже дело не в том, что оказалось оптимизации там нет никакой. Дело в универсальности. Если требуется создать бинарник, который поддерживается большинством железа, оптимизация на скорость и размер по умолчанию идёт лесом. Там вверху правильно заметили. Есть Gentoo. И фишка Gentoo как раз в том, что я мало того, что на своей системе собираю всё под один определённый проц, выкинув ненужные мне компоненты. За счёт этого и скорость. Но этот мой бинарник, собранный под двухядерный Athlon XP, не заработает на любой 32-битной системе и будет глючить на большинстве 64-битных. Зато у меня летает.
Если же стоит цель собрать пакет, который должен запустить на всём чём угодно, начиная от древних пентиумов и заканчивая какими-нибудь квадами, ни о какой оптимизации речи и быть не может.
Ну а что касается ключа -О, это уже давно размусоленная тема. Выше -О2 для стабильного пакета использовать не стоит, если не знаешь, ччто конкретно делаешь. Высокие уровни оптимизации завязаны на экспериментальные и/или нестабильные фишки компилятора. Те фишки, что в процеессе разработки хорошо себя зарекомендуют, со временем переносятся в -О2. Существуют, конечно, случаи, когда использование более высокого уровня оптимизации gcc полезно. Но чтобы это узнать, надо быть программистом, хорошо разбираться в самих фишках оптимизации и знать исходник компилируемой программы, чтобы быть уверенным в надёжности использованных в процессе написания функций.
Помню что в одном из проектов столкнулся с нереальными тормозами на FF. Помню тогда перепробовал ряд разных сборок, и вроде бы только swiftweasel действительно работал сильно быстрее (вместо трёхсекундного подвисания отрабатывал почти мгновенно). Правда swiftweasel уже давно не обновляется.