При оценке производительности Linux и Windows сборок Firefox 3 было обнаружено (http://www.tuxradar.com/content/benchmarked-firefox-javascri...) заметное отставание Linux версии. Тестирование проводилось тремя разными пакетами -
SunSpider (http://webkit.org/perf/sunspider-0.9/sunspider.html),
V8 Benchmark Suite (http://v8.googlecode.com/svn/data/benchmarks/v3/run.html), Mozilla Dromaeo (http://dromaeo.com/), в Fedora 10 все три теста показали явное отставание Linux сборки Firefox 3.0.6 от аналогичной версии браузера, запущенной в Windows XP SP3.
День спустя, тестирование было повторено. На этот раз, чтобы исключить возможные проблемы в сборке пакета для Fedora 10, тесты были проведены и для оригинальной Linux сборки с сайта Mozilla.
Для доказательства, что более высокая производительность связанна именно со сборкой Firefox, а не свойствами Windows, например, не вызвана разницей в скорости прорисовки графики из-за различных драйверов, Windo...URL: http://www.tuxradar.com/content/browser-benchmarks-2-even-wi...
Новость: https://www.opennet.ru/opennews/art.shtml?num=20269
Играю периодически в одну браузерку написаную на флеше, так в запущеном вендовом firefox под wine играть в неё нереально. Просто проверял.
Не знаю по чём они там такое решили - нету линукса под рукой чтобы проверить, но если флеш медленно переводит эмулированый фирефокс практически в однозадачный режим, так йоптель, флеш сейчас на каждом сайте :).
Сильно не пинайте. Возможно я чего-то недопонял)
под маком флеш тоже тормозит :(
и как связана производительность Firefox с производительностью Flash это совершенно разные программы.?Забавно, но с рендереингом 2д графике в лисе еще хуже. В Linux версии файфокс отвратительная производительность рендеренга прозрачных слоев, а сглаживание увеличенных изображений вообще отключено по сображениям производительности. Но в лисе запущенной из под wine все ок и с прозрачностью и со сглаживанием.
Дело тут походу в том, что чтобы это работало быстро в Linux разработчики должны написать свои алгоритмы композитинга и сглаживания,т.к. X-овые очень не оптимизированные, а аппаратное ускорение этих вещей ее отсутствует во многих драйверах. Мозиловцы не хотят идти таким не прямым путем и ждут когда ситуация исправится на стороне X-ов. Кажется в Xorg 7.5 этот момент будет решен уже да и аппаратным ускорение 2д под Linux вендоры активно занялись с момента выхода кде4.
Возникает ощущение что авторам мозиллы надо просто вставить пистон за плохую оптимизацию под линукс, а то когда под wine виндовый браузер обгоняет обычный - возникает резонный вопрос о качестве поддержки платформы... :).А то GDI в винде например тоже тормоз редкий и наврядли мозилла рендерит через директикс.
>GDI в винде например тоже тормоз редкийабсолютный бред!
вендовый gdi/gdi+ очень сильно надрочен на 2d-операции. и рендеринг выполняется на gpu в отличие от
>наврядли мозилла рендерит через директиксopera 10.5 переведет всю отрисовку на векторный движок, поддерживающий аппаратную акселерацию
Бугага...
Я тоже использую Linux как пускалку для Wine ))
Есть над, чем подумать. Графике, как бы она ущербной в глазах гиков не казалась, в реали является очень важной вещью. Не обращать внимания на производительность, стабильность и ресурсоемкость просто нельзя... Висты затопчут ;)
первое:
>Я тоже использую Linux как пускалку для Wine ))второе:
>Есть над, чем подумать. Графике, как бы она ущербной в глазах гиков не казалась, в реали является очень важной вещью.по первому и так ясно. даже боюсь спрашивать что ещё Вы не по назначению используете...
а вот по второму - а wine в линухе какую "графику" использует?действительно Бугага...
кто сказал что gcc - плохо оптимизирует?! :)
точнее g++
Я так и знал, что тут что-то нечисто! Разница в производительности заметна без всяких тестов.Очевидно мозилловцы делали продукт для винды, а потом через костыли прикрутили поддержку gtk и linux.
> Firefox 3 запущенный в Windows и Wine показал очень близкие результаты производительности, заметно опережающие запущенные в Linux версии Firefox из стандартного репозитория Fedora и c сайта MozillaНу если он даже под эмулированным GDI быстрее... Это камень в огород Gtk.
А при чем тут GTK? Надо дождаться сборки под Qt и еще раз потестировать.
Сборка тормозиллы под QT?!!
>Сборка тормозиллы под QT?!!ну да. в разработке, насколько я знаю.
>>Сборка тормозиллы под QT?!!
>
>ну да. в разработке, насколько я знаю.Если интересно можете скачать и проверить: правда сборка глючноватат еще
http://browser.garage.maemo.org/news/10/
4.4 - тормоз, надо дождаться под 4.5
Только тестировать будем релиз и не с 0 в минорном номере версии, ага. А то его недавно добавили и ещё долго сырое будет.
А причем здесь вообще GDI, GTK и QT?
тестировалась производительность Javascript движков.О производительности 2д мой каммент выше.
Ну тогда по вашему получается, что сейчас виндовые приложения в Wine через иксы без аппаратного 2D ускорения отрисовывают свою графику шустрее, чем Gtk-шные через те же самые иксы.
>А при чем тут GTK? Надо дождаться сборки под Qt и еще
>раз потестировать.Надо под винду с помощью gcc собрать и протестировать, думаю результаты будут одинаковые.
Opera 10 под Wine тоже быстрее.... V8 - 104 против 147 в среднем. Грустно.
я вот тоже думал... чего это Мозилла под Линухом такая тормознутая, но тем не менее её считают нормальным браузером.
оказывается дело в сильной платформозависимости кода
Ну, для меня это не стало великим открытием, всегда знал, что фирефокс под винду заточен. Зато когда у меня фирефокс начинает жутко тормозить, в отличие от винды, всё остальное имеет нормальный отклик.
Не знаю как у вас, а у меня Опера под Linux загружается быстрее чем под винду и работает отлично :) Версия 9.63
>Не знаю как у вас, а у меня Опера под Linux загружается
>быстрее чем под винду и работает отлично :) Версия 9.63Тесты прогоните. Я данные привел :)
У меня на убунте было тормознее виндовой, а в генте наоборот - быстрее (чем в ХР)!
подтверждаю: опенофис (кажется 2.4) виндовый под вайном(уж не помню каким, но в памяти сильно отпечаталось) в лине работает намнооого быстрее чем родной...
>подтверждаю: опенофис (кажется 2.4) виндовый под вайном(уж не помню каким, но в
>памяти сильно отпечаталось) в лине работает намнооого быстрее чем родной...а посему дело не только в мозиловцах
Зато виндовый под вендой работает медленнее, чем линуксовый под линуксом. Мистика.
Ж5 2х2ГГц ППЦ мак ос х
В8:
сафари 81
файрскунс 89
опера 72
МБП 2ГГц КореДуо мак ос х
В8:
сафари 158
файрскунс 132 (почти постоянно)
опера 108а теперь, внимание!... под Параллелс файрфокс - 134 (до 139)
параллелс с виндозой В2К
>Ж5 2х2ГГц ППЦ мак ос х
>В8:
>сафари 81
>файрскунс 89
>опера 722x2.3ГГц АМД
fedora 10opera 82.3
mozilla 96.9
epiphany 121
midori 289
konqueror 75.7и где тут справедливость???
Похоже GCC хуже оптимизирует код по сравнению с Visual C++ или в протестированных сборках случилось удачное выравнивание кода в ответственных частях Фокса для Windows и неудачное для Linux. Например, один и тот же код, выровненный по-разному (или невыровненный), скомпилированный Visual C++ легко может отличаться по производительности в 2 раза! Причем в каждом случае можно получать как прирост производительности на одних процессорах, так и падение на других; также может увеличиться производительность одних фрагментов программы, но упасть производительность других фрагментов.
>Похоже GCC хуже оптимизирует код по сравнению с Visual C++А при чём тут Visual C++ ?
>>Похоже GCC хуже оптимизирует код по сравнению с Visual C++
>
>А при чём тут Visual C++ ?при том что им собран билд Firefox'a под винду.
>при том что им собран билд Firefox'a под винду.А что под винду нельзя на гцц собрать?
>>>Похоже GCC хуже оптимизирует код по сравнению с Visual C++
>>
>>А при чём тут Visual C++ ?
>
>при том что им собран билд Firefox'a под винду.Точно? Сам проверял?
target
i686-pc-mingw32Build tools
Compiler Version Compiler flags
cl 14.00.50727.762 -GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 14.00.50727.762 -GR- -GL -wd4624 -wd4952 -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)Configure arguments
--enable-application=browser --enable-update-channel=release --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc --with-crashreporter-enable-percent=10Это и есть M$ Visual C++ ?
>target
>i686-pc-mingw32
>
>Build tools
>Compiler Version Compiler flags
>cl 14.00.50727.762 -GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE)
>
>Это и есть M$ Visual C++ ?Нее, это не Visual, это версия для бедных, без подсветки. Микрософт C/C++ тоже бывает без подсветки ))
>Нее, это не Visual, это версия для бедных, без подсветки. Микрософт C/C++
>тоже бывает без подсветки ))Бедные обладатели виндовс без Визуал Студио. :(
>Compiler Version Compiler flags
>cl 14.00.50727.762 -GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE)
>
>cl 14.00.50727.762 -GR- -GL -wd4624 -wd4952 -TP -nologo -Zc:wchar_t- -W3
>-Gy -Fd$(PDBFILE)
>
>Configure arguments
>--enable-application=browser --enable-update-channel=release --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc --with-crashreporter-enable-percent=10
>
>Это и есть M$ Visual C++ ?Я так понимаю, что ты намекаешь будто firefox под винду собирают GCC, так?
Тогда ты заблуждаешься.Если ты просто говоришь, что при сборке не используется IDE (Visual С++), то к сути вопроса это не имеет отношения, т.к. основное здесь - это то что firefox собран майкрософтовским компилятором, а использовалось ли при этом IDE, или собирали из комманд-лайна - дело десятое.
Скорее всего "cl(компилятор) 14.00.50727.762(его версия)" поставляется вместе с 2005-ой студией, а может с 2008-й, точно не знаю, врать не буду.
С 2003-й студией (без сервис паков) поставляется cl версии 13.10.3077.
>Configure arguments
>--enable-jemallocОпа опа, это жеж мегаускоритель жабаскрипта, и НАМНОГО быстрее чем glibc malloc в многопоточных программах!
>>Configure arguments
>>--enable-jemalloc
>
>Опа опа, это жеж мегаускоритель жабаскрипта, и НАМНОГО быстрее чем glibc malloc
>в многопоточных программах!Аноним, у меня Gentoo и я только что пересобрал firefox 3.0.6 и xulrunner с этой опцией. Прирост производительности в рамках погрешности. 127->133 в тесте v8
Ну дык это ведь и понятно. GCC-то всё делает по отдельным модулям, а потом уж их объединяет. А VC пытается сразу влезть во всё. Да, VC поэтому быстрее на порядок. Но поэтому же GCC существует для энного кол-ва платформ.
Линуксовые сборки сделаны без оптимизации вообще (см. about:buildconfig).Если бы кто-нибудь удосужился собрать у себя с -O3 и сравнить со штатным дистрибутивным — вот это было бы показательно с точки зрения возможностей оптимизации g++.
С другой стороны, если никто не удосужится — это тоже показательно :)
Уточнение: Один и тот же код, выровненный по-разному (или невыровненный), скомпилированный Visual C++ легко может отличаться по производительности в 2 раза от этого же кода, незначительно модифицированного в какой-нибудь неответственной части программы, скомпилированного этим же Visual C++!
ВНЕЗАПНО!!!
gcc плохо оптимизирует код, существует проблема с 2d-ускорением в иксах, барахлит шедулер...
а вы говорите "wine не нужен"
ещё как нужен! оказывается это отличный полигон для обнаружения узких мест в архитектуре
без вайна линуксоидам теперь никуда
>gcc плохо оптимизирует код,чем собирается сам wine?
>существует проблема с 2d-ускорением в иксах, барахлит шедулерзапущенные под wine приложения не используют 2d-ускорение в иксах?
>без вайна линуксоидам теперь никудаВы линуксоид? или просто советы даёте?
> чем собирается сам wine?Wine по умолчанию собирается с оптимизацией.
FF под линукс, похоже, по умолчанию собирается без таковой. about:buildconfig говорит, что флаги -Ox не использовались.
>> чем собирается сам wine?
>
>Wine по умолчанию собирается с оптимизацией.
>FF под линукс, похоже, по умолчанию собирается без таковой. about:buildconfig говорит, что
>флаги -Ox не использовались.x86_64-unknown-linux-gnu
Build tools
Compiler Version Compiler flags
gcc gcc version 4.2.1 (SUSE Linux) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Os -fno-strict-aliasing -fno-strict-aliasing -pthread -pipe
c++ gcc version 4.2.1 (SUSE Linux) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Os -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pthread -pipe
Configure arguments
--enable-application=xulrunner --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --mandir=/usr/share/man --includedir=/usr/include --enable-optimize --enable-extensions=python,default --with-system-jpeg --with-system-zlib --enable-xft --disable-freetype2 --enable-svg --enable-canvas --disable-tests --disable-mochitest --disable-installer --disable-javaxpcom --disable-crashreporter --enable-startup-notification --enable-url-classifier --with-system-nspr --with-system-nss
А вот вам убунта...about:buildconfig
Build platform
target
i686-pc-linux-gnuBuild tools
Compiler Version Compiler flags
cc gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -g -fno-strict-aliasing -pthread -pipe
g++ gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipeConfigure arguments
--build=i486-linux-gnu --prefix=/usr '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var '--libexecdir=${prefix}/lib/xulrunner-1.9' --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --enable-system-cairo --enable-system-sqlite --with-system-nspr --with-system-nss --enable-application=xulrunner --enable-extensions=xml-rpc,venkman,inspector,gnomevfs,cview,tasks,reporter,python/xpcom --enable-webservices --enable-safe-browsing --with-default-mozilla-five-home=/usr/lib/xulrunner-1.9.0.6 --enable-startup-notification --with-user-appdir=.mozilla --without-system-jpeg --with-system-zlib=/usr --with-system-bz2=/usr --enable-system-hunspell --disable-javaxpcom --disable-crashreporter --disable-elf-dynstr-gc --disable-installer --disable-strip --disable-strip-libs --disable-install-strip --disable-tests --disable-mochitest --disable-updater --enable-optimize --with-distribution-id=com.ubuntu
>А вот вам убунта...
>... -g ...М-да.
ALT Linux:
Build platform
target
i586-alt-linux-gnuBuild tools
Compiler Version Compiler flags
gcc gcc version 4.3.2 20081105 (ALT Linux 4.3.2-alt7) (GCC) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -pipe -Wall -O2 -march=i586 -mtune=i686 -fPIC -DPIC -fno-strict-aliasing -pthread -pipe
c++ gcc version 4.3.2 20081105 (ALT Linux 4.3.2-alt7) (GCC) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -pipe -Wall -O2 -march=i586 -mtune=i686 -fPIC -DPIC -fno-strict-aliasing -fshort-wchar -pthread -pipeConfigure arguments
--build=i586-alt-linux --host=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --includedir=/usr/include --disable-activex --disable-activex-scripting --disable-tests --disable-installer --disable-updater --disable-crashreporter --disable-mochitest --disable-freetype2 --disable-javaxpcom --disable-elf-dynstr-gc --enable-xft --enable-crypto --enable-application=xulrunner --enable-optimize=-O2 --enable-default-toolkit=cairo-gtk2 --enable-canvas --enable-safe-browsing --enable-url-classifier --enable-jemalloc --enable-oji --enable-strip --enable-install-strip --disable-debug --enable-svg --enable-svg-renderer-cairo --enable-libxul --enable-system-sqlite --enable-system-hunspell --enable-extensions=default,python/xpcom --without-system-png --enable-places --enable-storage --enable-system-lcms --enable-system-cairo --with-system-nspr --with-system-nss --with-system-jpeg --with-system-zlib --with-system-bz2 --with-pthreads
>>А вот вам убунта...
>>... -g ...
>
>М-да.
>
>ALT Linux:
>-fPIC -DPIC - это на всякий случай???? А вдруг неправильная либа прилипнет??? :) Или чего-то испугались.
>-fPIC -DPIC - это на всякий случай???? А вдруг неправильная либа
>прилипнет??? :) Или чего-то испугались.Точно не знаю (или забыл), но см. тж. http://www.altlinux.org/UpStream/AsNeeded
> доковыривание до источника проблемы в Makefile.am может быть не совсем интересным занятием...Ну так не надо писать если хотят на этом денег зарабатывать...
Всем лень, - вот и доигрались, в режиме эмуляции работает быстрее syscall_офф.
>>А вот вам убунта...
>>... -g ...
>
>М-да.
>Собирают с отладкой, чай не встраиваемая система, мегабайты на диске найдутся. Не вижу повода для уныния ))
>>>А вот вам убунта...
>>>... -g ...
>>М-да.
>Собирают с отладкой, чай не встраиваемая система, мегабайты на диске найдутся.И в памяти, и в кэше, и циклы процессорные. Да и пользователю спешить некуда.
>Не вижу повода для уныния ))
Да не, что Вы. Унывать -- это не для среднего убунтушника, впрочем, как и задумываться. :]
>>>>А вот вам убунта...
>>>>... -g ...
>>>М-да.
>>Собирают с отладкой, чай не встраиваемая система, мегабайты на диске найдутся.
>
>И в памяти, и в кэше, и циклы процессорные. Да и
>пользователю спешить некуда.В оперативную память отладочная информация не попадает (если только её отладчик не читает) На циклы процессорные (и вообще на инструкции машинных кодов) наличие или отсутствие отладочной информации также не оказывает влияния. В gcc оптимизация и отладка абсолютно независимы и могут быть использоваться в любом сочерании.
>
>>Не вижу повода для уныния ))
>
>Да не, что Вы. Унывать -- это не для среднего убунтушника,
>впрочем, как и задумываться. :]Задумываться хорошо, но ещё лучше разобраться, вместо того чтобы ныть и подозревать.
>В gcc оптимизация и отладка абсолютно независимы и могут быть использоваться
>в любом сочерании.Первый раз слышу, причём из недоверенного источника. Обратное слышал не раз и из куда более доверенных. Читать на спор с незнамо кем, как там в 4.3, лень.
Далее, -O я там тоже не вижу. Ну и с -g обычно не стрипают бинарники (нет, выковыривать и смотреть тоже лень).
>Задумываться хорошо, но ещё лучше разобраться, вместо того чтобы ныть и подозревать.
Вот и разберитесь.
>>В gcc оптимизация и отладка абсолютно независимы и могут быть использоваться
>>в любом сочерании.
>
>Первый раз слышу, причём из недоверенного источника.
>Обратное слышал не раз и из куда более доверенных.И что-же это за более доверенные источники, которые явно не читали руководство по gcc, и не знают как работает в linux exec, и что он при своей работе загружает?
>Читать на спор с незнамо
>кем, как там в 4.3, лень.А сопли надувать и писать чушь не лень? Или умойся, всё ты прочитал уже, и поняв что не прав начал бычить ))
Разобрался с тобой.
в Debian Lenny примерно та же хрень. Интересно было бы послушать аргументацию мантейнеров. На переименование (или как они это называют) у них хватает времени и усилий, а на то, чтобы поиграть с опциями оптимизации или просто включить унылый -02 у них руки не доходят.Есть одно предположение: У gcc похоже проблемы с оптимизацией под одну и поддерживаемых Debian'ом платформ. При компиляции Iceweasel'а с опцией оптимизации под эту платформу вылазят ошибки. Ну и...
>> Тип: Тема для размышления"А что тут прозревать, то? Значит, вы вошли, переставили мебель, поменяли тарелки..."
>> кто сказал что gcc - плохо оптимизирует?! :)
если это не сарказм,
то как раз по этим тестам и видно, что плохо.>> Очевидно мозилловцы делали продукт для винды, а потом через костыли
>> прикрутили поддержку gtk и linux.
>> Ну если он даже под эмулированным GDI быстрее... Это камень в огород Gtk.gtk тут не причем, меряли JavaScript, большей частью бекэнд.
>> Opera 10 под Wine тоже быстрее.... V8 - 104 против 147 в среднем. Грустно.
проблема, наверняка, аналогична Firefox'у.
>> Просто под винду из жопы лезут, но оптимизируют и код и саму сборку как
>> надо, а на юникс кладут.JavaScript - это большей частью бекэнд. Оптимизируя бекэнд на винде, автоматически оптимизируется под юникс, обратное также верно.
>> а посему дело не только в мозиловцах
к Firefox'у и Oper'е могу добавить и Quake3. Который виндовый под
Wine давал больший FPS чем нативный линуксовый.А разница у всех этих программ одна и очень существенная:
под винду бинари собирают M$-ским компилятором, а под linux - GCC'ёй.+ к этому, при сборке firefox'а 3.x на винде включена "profile-guided optimization", что тоже вносит свой вклад в ускорение собранной программы.
>к Firefox'у и Oper'е могу добавить и Quake3. Который виндовый под
>Wine давал больший FPS чем нативный линуксовый.Уж давно неправда
>+ к этому, при сборке firefox'а 3.x на винде включена "profile-guided optimization",
>что тоже вносит свой вклад в ускорение собранной программы.gcc тоже умеет оптимизировать по профилю. И вообще умеет оптимизировать. Вот только кладут на это мурзилы, собирая кое как, не включая даже малейшие оптимизации.
У меня была Федора, так там действительно Firefox безбожно тормозил. Я поставил сборку с официального сайта мозиллы и все стало хорошо.
Сейчас у меня Зенволк и сборка с сайта мозиллы. Никакой разницы с виндовым вариантом я не чувствую.
Какую еще им нужна производительность в броузерах я не понимаю. Браузеры нормальную скорость выдавали еще на компах десятилетней давности.
Люди явно не теми проблемами озабочены. Лучше бы подумали над полезными новыми функциями и поддержке всех фич новых и недоделанных старых стандартов.
http://v8.googlecode.com/svn/data/benchmarks/v3/run.html
Score: 2200 - Midori (Webkit)
Score: 218 - Epiphany (Gecko 1.9)
Score: 206 - Firefox 3.0.5 (ebuild)
Score: 187 - Opera 10.00 Build 4166 Qt library 4.4.2
Ubuntu 8.04.2Midori 0.0.17: 145
Firefox 3.0.6: 149
Opera 9.61: 119
780.6ms - Midori 0.1.2-3c75e9e (net-libs/webkit-gtk 0_p40220)
2482.2ms - Epiphany (Gecko 1.9)
2563.4ms - Firefox 3.0.6 (www-client/mozilla-firefox)
4063.6ms - Opera 10.00 Build 4166 Qt library 4.4.2Midori ревет в пух и прах.
http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html
Эта новость уже была! Только для второй версии браузера. Значит, ждите версию 4 через полгода!
>Эта новость уже была! Только для второй версии браузера. Значит, ждите версию
>4 через полгода!потом пятую через год, потом ещё шестую версию гцц через год, потом ещё чего-то... или просто используйте виндовс (уж извините за троллинг, просто так оно выглядит со стороны)
А если собрать при помощи Intel C compiler?
>А если собрать при помощи Intel C compiler?нафиг, нафиг крейга барета кормить :)
>А если собрать при помощи Intel C compiler?Intel C compiler под Windows во многих случаях генерирует более медленный код, чем MSVC и даже Borland.
Странно, но у меня прямо противоположные впечатления от рендеринга html+js.
http://v8.googlecode.com/svn/data/benchmarks/v3/run.html
Swiftfox 219
Epiphany 211
Konqeror 29.6 =)
wine + firefox 257
при етом фаерфокс под вайном проигрывает свифтфоксу весьма существенно в тесте Crypto
237 у swiftfox против 175 к firefox+wine
имхо в инете даже на 500мгц системе весьма комфортно лазить... а на современной.. вообщем это уже несущественно
тестировал год назад работу одного математического алгоритма, никакого 3D, 2D, просто консоль, сборки в винде осуществлял bcc, gcc, VC так вот самый скоростной код получался у VC и bcc (борман был шестой), а вот код собранный gcc заметно тормозил. Насколько помню цифры типа 1-1,5 сек. против 7сек. несмотря на -O2.
>тестировал год назад работу одного математического алгоритма, никакого 3D, 2D, просто консоль,
>сборки в винде осуществлял bcc, gcc, VC так вот самый скоростной
>код получался у VC и bcc (борман был шестой), а вот
>код собранный gcc заметно тормозил. Насколько помню цифры типа 1-1,5 сек.
>против 7сек. несмотря на -O2.-O2 только абсолютно безопасные оптимизации, и от того не сильно эффективные.
Всякие unroll fast-math и omit-fp не включаются при -O2.
Дайте исходник, за 0.5 сек. заработает!!!
Один человек уже высказал правильную мысль:
> Линуксовые сборки сделаны без оптимизации вообще (см. about:buildconfig)Так что вообще не понятно что вы тут обсуждаете. Т.е. в линуксовой версии оптимизации нет никакой (ни -O1, ни -O2, ни -O3)! Поэтому притензии к X, gcc и прочим вещам совершенно беспочвенны.
x86_64-unknown-linux-gnuBuild tools
Compiler Version Compiler flagsgcc gcc version 4.2.1 (SUSE Linux) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Os -fno-strict-aliasing -fno-strict-aliasing -pthread -pipe
c++ gcc version 4.2.1 (SUSE Linux) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Os -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pthread -pipe
Configure arguments
--enable-application=xulrunner --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --mandir=/usr/share/man --includedir=/usr/include --enable-optimize --enable-extensions=python,default --with-system-jpeg --with-system-zlib --enable-xft --disable-freetype2 --enable-svg --enable-canvas --disable-tests --disable-mochitest --disable-installer --disable-javaxpcom --disable-crashreporter --enable-startup-notification --enable-url-classifier --with-system-nspr --with-system-nss
На SUSE видимо сборка оптимизрованная. Осталось только проверить именно на ней всё остальное.
-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -O3 -march=athlon64 -pipe -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -pthread -pipe
скоро google допилит свой хром под линукс и можно забыть про фаирфокс
я специально привел тесты под маком!
https://www.opennet.ru/openforum/vsluhforumID3/49395.html#24под интелем в виртуальной машине ФФ оказался быстрей, чем в хозяйской системе!
при этом можно исключить влияние графической подсистемыпод вайном часто сталкивался с ситуёвиной - отсутствие отрисовки (т.е. - просто не заморачиваются обновлением экрана)
предлагаю проводить тест под вайном в свернутом окне - возможно резалты будут ещё выше ;)
Возможно, MS платит Мозилловцам не только за неоптимизацию FF под Linux, но и специальную деградацию производительности.
Вспомните, пару лет назад, когда перестали делать FF под win98, на официальных форумах мозиллы резали темы с протестами.
>Firefox запущенный в Wine обогнал по производительности родную Linux-сборку.Я это еще давно знал. Разница заметна на P4 3.2 ghz
Флеш вообще дико тормозит. Но даже на страницах без флеша в Линуксе тормозит сильнее. Вывод я делал такой, что Линукс технологически хуже.
>>Firefox запущенный в Wine обогнал по производительности родную Linux-сборку.
>
>Я это еще давно знал. Разница заметна на P4 3.2 ghz
>
>Флеш вообще дико тормозит. Но даже на страницах без флеша в Линуксе
>тормозит сильнее. Вывод я делал такой, что Линукс технологически хуже.ога - очень глубокий вывод ;) Институт-то умудрились закончить (хотяб на троечки) ;) ?
вывод они делали, а что ещё делали? ;)
вы хоть представляете как и что и где работает?!, я слабо и потому сомневаюсь, а тут - "вывод"!
>Вывод я делал такой, что Линукс технологически хуже.чем что?
>>Вывод я делал такой, что Линукс технологически хуже.
>
>чем что?чем технологически :)
>ghzнаучитесь физические величины писать правильно! а потом уже делайте свои глупые выводы и желательно не в слух.
Кстати с Gimp'ом ситуация обратная - в винде он у меня загружается раза в два дольше, чем в убунте.
>Кстати с Gimp'ом ситуация обратная - в винде он у меня загружается
>раза в два дольше, чем в убунте.Надо пологать что дело в GTK и что в бунте львинная доля этих либ к моменту запуска гимпа уже находятся в памяти.
и не только.
сравните скорость и удобство работы того же pidgin.
виндовая версия создаёт впечатление унылого и тормозного поделия.
одна полная перерисовка окна чего стоит... под линухом же - отличный им.
и так со всеми гтк-ашными программами...
кто пробовал kde4 под виндами и линухом, поделитесь впечатлениями?p.s.:
на основании вышесказанного уже можно делать вывод, что винда технологически хуже? :-DDDDD
>кто пробовал kde4 под виндами и линухом, поделитесь впечатлениями?не советую :)
это зрелище не для слабонервных. дольше пяти минут работает лишь парочка казуальных игр, остальные приложения текут и крашатся. про гуевые тормоза, думаю, не стоило и упоминать
pidgin и в Linux'е унылое и тормозное поделие. Особенно, когда пытаешься использовать помимо аськи еще и jabber-протокол. И, не дай вам бог, еще какой-нить протокол...Непонятно только одно: Кроссплатформенное оно по определению не эффективное. Точнее кроссплатформенность достигается за счет универсализации кода, отказа от использования специфики конкретной платформы.
По этой причине эффективность компилятора gcc заведомо ниже, чем у компиляторов написанных под конкретную платформу (oперационка + cpu).
Другое дело, что высокая эффективность кода в настоящее время не очень актуальная тема. А вот благами кроссплаформенности пользуются практически все. И, увы, эти блага обходятся не бесплатно...
Так вот непонятно, а что, собственно, народ во всем этом удивляет.
>pidgin и в Linux'е унылое и тормозное поделие. Особенно, когда пытаешься использовать помимо аськи еще и jabber-протокол. И, не дай вам бог, еще какой-нить протокол...великолепно работаю с тремя протоколами. нареканий нет. обычный Pidgin 2.5.2. даже не обновлял. причём настолько хорошо, что счастливые пользователи qip посмотреть. :-)
>По этой причине эффективность компилятора gcc заведомо ниже, чем у компиляторов написанных под конкретную платформу (oперационка + cpu).Вы видимо не в курсе архитектуры gcc. для ознакомления посмотрите это - http://www.ibm.com/developerworks/ru/library/l-gcc4/index.html
GCC расшифровывается как GNU Compiler Collection - набор компиляторов GNU.
у меня есть свои небольшие претензии, но это точно не к оптимизации и качеству.
>великолепно работаю с тремя протоколами. нареканий нет. обычный Pidgin 2.5.2.
>даже не обновлял. причём настолько хорошо, что счастливые пользователи qip посмотреть. :-)Могу лишь только позавидовать. У меня после пары-тройки дней работы в онлайне сие чудо начинает отваливаться от сервера джаббера и попытки реконнекта начинают тормозить pidgin'а целиком. Приходится его перезапускать... Если вы при старте неправильно ввели пароль jabber'у, то он будет пытаться с упорством идиота приконнектиться с неправильным паролем, вместо того, чтобы снова его запросить, и при этом тормозить работу по другим протоколам где логин прошел нормально. И т.д. и т.п... В итоге после очередного последнего прикола аськи просто сбежал с него.
>Вы видимо не в курсе архитектуры gcc. для ознакомления посмотрите это -
>http://www.ibm.com/developerworks/ru/library/l-gcc4/index.html
>GCC расшифровывается как GNU Compiler Collection - набор компиляторов GNU.Ну и? Что я там написано такое, что отвергает правоту моих слов. Поддержка дополнительного уровня абстракции вне зависимости от названия (SSA-деревья или RTL-код) в любом случае требует дополнительных затрат.
Потом, я вообще не нашел упоминания об оптимизации на уровне системы команд целевой платформы. Получается, что вся имеющаяся оптимизация gcc работает исключительно с промежуточным представлением? Ну-ну...
Тогда берем нормальные книжки по программированию на ассеблере середины 90-х прошлого века, читаем разделы касающиеся оптимизации, зависящей от особенностей архитектуры процессоров внутри семейства x86. Офигеваем от числа нюансов и прироста производительности. Включаем мозги и экстраполируем полученные сведения на принициально отличные архитектуры процессоров. Готов поспорить результат вам понравится.Более того, если бы и в самом деле gcc был так хорош, то смысла в таком разнообразии архитектур процессоров, не говоря уже о системах) просто бы не было.
>у меня есть свои небольшие претензии, но это точно не к оптимизации и качеству.
Ну это лишний раз подверждает мои слова: Что высокая эффективность оптимизации на нынешнем этапе развития малоактуальна.
>[оверквотинг удален]
>вам понравится.
>
>Более того, если бы и в самом деле gcc был так хорош,
>то смысла в таком разнообразии архитектур процессоров, не говоря уже о
>системах) просто бы не было.
>
>>у меня есть свои небольшие претензии, но это точно не к оптимизации и качеству.
>
>Ну это лишний раз подверждает мои слова: Что высокая эффективность оптимизации на
>нынешнем этапе развития малоактуальна.Тормоза с реконектом к жаббер серверу - баян, скачай исходник послденей версии и будет тебе счастье, а ещё больше щастья если разберёшся с опциями и собирёш такой как тебе нужен =)
Проект по портированию Firefox на Qt не развивается?
На сайте http://browser.garage.maemo.org/news/ новостей нет.
V8
Дома на HP nx7400 (Core Duo T2300 @ 1.66 GHz, 1.5 GB RAM):
Firefox 3.0.4 FreeBSD 8-CURRENT (с WITNESS, INVARIANTS):
93-98Firefox 3.0.6 Fedora 10:
70-80На работе AMD Athlon 64 X2 4400+, 3Gb RAM, 32bit Fedora 10
Firefox 3.0.6: 45-50 !!!!?!?!??!
Wine + Firefox 3.0.6: 100-107
на фре пересобери фокс с OPTIMIZED_CFLAGS будет ещё больш, венду перегонит =)
>[оверквотинг удален]
>93-98
>
>Firefox 3.0.6 Fedora 10:
>70-80
>
>На работе AMD Athlon 64 X2 4400+, 3Gb RAM, 32bit Fedora 10
>
>
>Firefox 3.0.6: 45-50 !!!!?!?!??!
>Wine + Firefox 3.0.6: 100-107только что проверил
core2duo E6550, 2G RAM, MB MSI G31, video GF8600GT остальное железо думаю не критично...Win XP SP2 сегодня установленая (практически чистая)
V8
FireFox 3.0.6 - 210-215 - запускал раз пять наверноета же машина через 5 минут на Gentoo 32 bit
FireFox 3.0.6 - 160-165 - запускал 3 разa
на Gentoo 64 разрядной не пробовал. Еще не закончил установку. когда все поставлю попробую еще и на ней. Ради эксперимента.
>[оверквотинг удален]
>Win XP SP2 сегодня установленая (практически чистая)
>V8
>FireFox 3.0.6 - 210-215 - запускал раз пять наверное
>
>та же машина через 5 минут на Gentoo 32 bit
>
>FireFox 3.0.6 - 160-165 - запускал 3 разa
>
>на Gentoo 64 разрядной не пробовал. Еще не закончил установку. когда все
>поставлю попробую еще и на ней. Ради эксперимента.Проверил на 64-разр.
FireFox 3.0.6 - 171-175
наводит на размышления?
помнится CS под вайном бегал быстрее чем на венде :)
Ноут (C2D 9500/4Gb/Intel X3100) Ubuntu 8.10
Opera 10.4126 133
Firefox 3.06 195
IE6 (wine) 40 (с ошибкой)Сервер (Phenom 9550/4Gb/Radeon 4850) openSUSE 11.1
Opera 9.63 120
Firefox 3.06 178
Epiphany 2.24.1 176Игровая (Athlon X2 5000+/3Gb/GF8800GTS) Vista 32 SP1
Opera 9.63 164
IE7 48 (тоже с ошибкой в ходе теста, бу-га-га)
...За окном шел 2013 год, и текущим релизом файрфокса был 18.02. А он все так же под вайном работал в разы быстрее, чем нативный линуксовый (без всяких тестов, даже визуально заметно), да и выглядел красивее...
> ...За окном шел 2013 год, и текущим релизом файрфокса был 18.02. А
> он все так же под вайном работал в разы быстрее, чем
> нативный линуксовый (без всяких тестов, даже визуально заметно), да и выглядел
> красивее...И не говори, причём чем производительность нижается по меред открывания разных страниц, появляются фризы, даже если удалить places.sqlite и повыключать все плагины, с flash вообще не жизнь, но и просто js похоже плохо сказывается... И вообще для браузера подход с classic-архитектурой в nix правильнее...