Сравнение производительности Javascript на Mozilla Firefox 3.5 (Linux)

Всем уже известно, что в новый Firefox 3.5 разработчики включили быстрый JavaScript-движок TraceMonkey. Утверждалось, что он разрывает в клочья V8, который используется в Google Chrome. Здесь уже пробегало достаточно постов по поводу того, насколько всё будет хорошо и замечательно, настало время это проверить :)

Вообще неплохо было бы проверить оригинальную заявку про разрывание в клочья V8 на Windows, но для начала я взял свой рабочий Gentoo Linux x86 на ThinkPad T61 (Core2Duo 2.0 Ghz / 2 GB RAM), несколько версий Firefox, Opera и последний билд Chromium, да классический Javascript-тест SunSpider.

Итак, что мы имеем по браузерам:
  1. Mozilla Firefox 3.0.11, собран из исходников с оптимизацией [*]. Буду использовать его как версию FF без TraceMonkey.
  2. Mozilla Firefox 3.5 (binary), скачан с сайта Mozilla. Буду использовать его как сборку без архитектурно-специфичных оптимизаций.
  3. Mozilla Firefox 3.5 (source), собран из оверлея с оптимизацией [*]. Хочу посмотреть, как влияет производительность самого TraceMonkey.
  4. Mozilla Firefox 3.5 (source + custom), собран из оверлея с оптимизацией [*] и выставленным флагом «custom-optimization».
  5. Opera 9.64, бинарная сборка, доступная из репозитория.
  6. Chromium 3.0.192.0 (19918), скачанный с сайта проекта Chromium. К сожалению, официального релиза Chrome под Linux нет, поэтому пришлось использовать ночной билд.

[*] У меня в /etc/make.conf по-умолчанию включены следующие оптимизации: "-O3 -march=prescott -fomit-frame-pointer -fexpensive-optimizations -pipe". Пакеты, правда, вправе их проигнорировать.

Каждый тест запускался в «чистом» окружении: запущен только KDE, все посторонние процессы выгружены, браузер был единственным открытым приложением, в браузере открыт только SunSpider. Перед запуском каждого браузера проверялась 0% CPU активность в течении минуты. Браузеры стартовали с настройками по-умолчанию, с новыми профилями.

Для начала картинка для привлечения внимания. Общий результат:

SunSpider измеряет время исполнения, поэтому чем меньше время, тем лучше. Видно, что производительность FF действительно выросла, причём значительно! Opera повела себя вообще странно, а Chromium вырвался вперёд. В принципе, на этом можно было бы и закончить, остальная часть поста только детализирует эту картинку.

Для удобства нормализуем по FF 3.0.11:

Видно, что прирост производительности зашкалил за 100%, т.е. больше чем в два раза. Chromium был быстрее в 6(!) раз.

Пробежимся по каждой группе тестов в отдельности, всё ещё нормализуем по FF 3.0.11:

Видно, что изменения коснулись каждого из тестов, кроме controlflow. Практически на каждом из них наблюдаются приросты минимум два раза, а на некоторых и в семь раз.

Хорошо, FF 3.0.11 уже не конкурент, оставим его в покое, нормализуем теперь по самой быстрой версии FF 3.5:

А Chromium с его V8 всё ещё в 2.5 раза быстрее.

Опять же, подробнее по тестам:

По этой картинке можно сказать, что FF с TraceMonkey только почти только догнал Chromium с V8 только на одном из тестов — bitops. Во всех остальных случаях Chromium уверенно побеждает.

За точными данными, расчётами и построением графиков можно обратиться в протокол эксперимента. Будет здорово, если кто-нибудь сможет взять машинку с установленной Windows XP / Vista и повторить этот эксперимент. Нужно будет только ввести числа (ну и лишние колонки посносить), всё остальное пересчитается и перестроится само.

UPD: Auren откликнулся и проверил это на Windows 7.

Напоследок disclaimer: этот эксперимент НЕ может являться доказательством тотального превосходства V8 над TraceMonkey. Товарищи из Mozilla/Google лучше знают, как измерять производительность своих продуктов. Показываю только то, что вижу на отдельно взятой системе, на отдельно взятом тесте. И да, FF 3.5 визуально гораздо быстрее :)


_________
Текст подготовлен в ХабраРедакторе (и допилен руками)
+36
4 июля 2009, 17:52
3
TheShade 213,1

комментарии (53)

+1
DileSoft #
Странно, но на этом (http://people.mozilla.com/~schrep/image12.html) тесте у меня Chrome (3.0.190.4) в 4 раза медленнее, FF 3.5
+1
DileSoft #
+1
TheShade #
Ага, у меня Chromium проигрывает FF 3.5: 3601ms против 9381ms, т.е. в 2.6 раза медленнее. Собственно, это прекрасная иллюстрация к моему дисклеймеру в конце поста :)
0
TheShade #
У меня, кстати, в FF 3.5 пропускает кадры: сначала наблюдаю плавное перетекание, потом всё замирает на ~50% прозрачности, потом ничего не происходит, потом тест заканчивается. Chromium медленно, но верно отрисовывает. По-моему, это звоночек, то ли для теста, то ли для движка.
0
DileSoft #
А у меня всё в порядке. Но в фф действительно есть микрозамирания — это глюк именно трейсманки. Еще зависит от того, что открыто в соседних вкладках.
0
DileSoft #
а, стоп. так и должно быть. ползунок ползет до той точки, до которой он в последний раз был оставлен.
НЛО прилетело и опубликовало эту надпись здесь
+1
TheShade #
Десятая Опера — это всё-таки бета. Мне нужна была какая-нибудь вразумительная точка отсчёта для основных браузеров, поэтому я и взял последнюю стабильную версию 9.64. Вы можете сами потестить, на сколько Opera 10 быстрее :) Я тут померил, оказалось, что на моей системе она проходит SunSpider за 6 секунд, т.е. намного быстрее Opera 9, но всё-таки очень медленно по сравнению с FF и Chromium. Не стал добавлять на график, чтобы не его данными не перегружать.
0
Davidov #
Странно; я вчера скачивал: мне предложили 10.

Вот мои результаты для Firefox 3.0.14, последнего билда Chromium и Opera 10.00; Sunspider.

0
Davidov #
Упс; не посмотрел на дату :(
+3
homm #
А почему взяли оперу, выпущенную 2 года назад, а не 4?
0
TheShade #
Виноват, опечатался, в тесте участвовала Opera 9.64, она же последняя стабильная, которую предлагают на сайте Opera. Сейчас поправлю.
0
homm #
Ну а без минусов в карму совсем не как?
Для особо одаренных: возможно до моего комментария статья выглядела несколько иначе, правда?
–10
evil_random #
присунул за нытье
–2
homm #
«присунул»? Ты наверное очень крут.
–4
evil_random #
невероятно!
как американцы говорят: awesome!
НЛО прилетело и опубликовало эту надпись здесь
–5
homm #
Иной раз и не такое на хабре увидишь!
+1
XPilot #
0
TheShade #
А некислое у Вас там исследование. Где-нибудь можно про сами эксперименты почитать: как производились, что было кроме этого было запущено, и т.п.?
0
XPilot #
Берем браузер, устанавливаем, выключаем все программы и процессы (поскольку, запуски сильно разнесены по времени [эта таблица собрана за несколько месяцев], то старался вырубить все, что могло помешать, но, конечно, есть вероятность, что в каком-то из тестов какая-нибудь программа могла висеть в процессах [но BOINC всегда вырубал ;)] ), запускаем браузер с чистым профилем, запускаем тесты — все стандартно и рутинно :) После теста копируем сырые результаты в OO.o Writer/Calc и публикуем на Google Docs…

Лист с SunSpider самый полный, поскольку его легко выполнять, тестов не очень много и можно легко проверить, если при перепечатке чисел где-то ошибся…

Dromaeo — очень большой и очень длинный, тесты медленные (часть из них взята со SunSpider), поэтому там пока всего 4 позиции, возможно позже я его дополню.

penroseTiling — увы, на странице тест выполняется только один раз, поэтому после каждого прогона очищал кэш и запускал занового (по 10 на браузер, хотя, конечно, можно было бы и по-больше)

Peacekeeper — увы, придется удалить или что-то еще с ним сделать: Futuremark изменили тест…
0
XPilot #
Все браузеры — бинарные сборки, взятые с сайтов вендоров (то есть это те продукты, которые предлагаются пользователям)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
+1
TheShade #
Большое спасибо за помощь!
+1
PsySonic #
Мне уже несколько надоело, что файерфокс мериется странной фигней вроде вырожденных тестов и контрастности картинки. Научился бы рендерить страницу лучше побыстрее, а то на 400 мегагерцовых арм процессорах им практически невозможно пользоваться.
0
Iskin #
Ну все этим же и меряются. Для нормальной оптимизации нужен benchmark. А загрузка страницы очень непостоянный процесс, который также сильно зависит от субъективного фактора.
0
TheShade #
Этот топик про Javascript. У вас есть замечание по методологии тестирования конкретно Javascript-движков? Про бенчмарки для рендеринга тоже говорят, но их реально очень сложно сделать, особенно кросс-браузерные.
0
XPilot #
>>«У вас есть замечание по методологии тестирования конкретно Javascript-движков?»
Предлагаю еще протестировать в Dromaeo
0
PsySonic #
>У вас есть замечание по методологии тестирования конкретно Javascript-движков?

Если вопрос не риторический, то соображения у меня есть.
Мне кажется если мерить JS то надо было бы делать бенчмарк на основе картографических сервисов (там ведь есть api), хитрых блогодвижков вроде хабровского и в гугл докс (там уже появились скрипты). По крайней мере мне скорость на данный момент не хватает именно для таких сайтов. Только вот нехватает ее на мобильных устройствах, где эти замечательные JS виртуальные машины в современных браузерах работать не будут.

По этому и я говорил о том, что на данный момент острой необходимости в проведении этих странных JS тестов КМК нет. Есть просто мода.
0
TheShade #
Dromaeo под Ваше определение подходит?

Мобильные устройства уже идут в сторону когда-то только десктопных приложений, когда-то только десктопных операционок и когда-то только десктопных архитектур. Поэтому то, что сейчас делается в десктопных браузерах со временем перекочует на мобильные устройства. Просто так взять и разогнать мобильный браузер, а тем более соорудить там Javascript-овский компилятор в натив — это чересчур дорого стоит.
0
lexa0 #
А почему забыли Koqueror? наверняка он уже стоит.
0
TheShade #
Забыл. У меня он вообще не ассоциируется с браузером, только с бегалкой по файловым системам :)
Не буду добавлять, потому что на той же системе он в 23 раза медленнее FF 3.5.
0
lexa0 #
Конкерор, как и kde3 неразвиваются полтора года как. Все усилилия разработчиков направлены на kde4. Потому и надо тестировать новый Konqueror и желательно с webkit.
0
homm #
WinXP

Opera 10 Firefox 3.5

Разница все равно в 3 раза.
–1
PsySonic #
Во всех браузерах кроме оперы уже виртуальная машина для JS. А опера хоть и объявила что напишут, но вы же понимаете, что им важна возможность запускать браузер под разные процессоры а виртуалка привязывает к архитектуре проца (существующие к х86). Так что чудес не стоит ждать.
0
nerezus #
ru.wikipedia.org/wiki/Виртуальная_машина
ru.wikipedia.org/wiki/JIT

Ты путаешь эти термины.
0
PsySonic #
Эту путаницу не я начал, я просто называю устоявшимся термином. Если всетаки изначальное название победит, буду только рад, но история показывает массу примеров, когда название чего-либо переносясь на другое меняло смысл.
0
nerezus #
Можно не JIT-компилить джаваскрипт, а выполнять его на VM. Разница будет незначительной в скоростях, но VM будет кроссплатформенной.
НЛО прилетело и опубликовало эту надпись здесь
–2
danilissimus #
под Windows 7 64-bit (2 GB RAM, Intel Core 2 Duo) Opera 10.00 Beta выполняла тест 3999 мс.
0
TheShade #
Дак это, вы апельсины с яблоками не сравнивайте. Сколько на этой системе FF 3.5 сделал?
0
danilissimus #
Total: 1054.4ms ± 24.0%
:)
0
non7top #
хотелось бы еще увидеть konqueror разных версий и midori. а то как-то кривобоко.
0
non7top #
сам же себе и отвечу

Firefox 3.5 (Iceweasel) — 1403.8ms ± 2.3%
Midori 0.1.5 — 873.4ms ± 3.3%
Konqueror 3.5.10 — 33787.2ms ± 1.2%
Konqueror 4.2.4 — не прошел до конца
Opera 10.00 Beta Build 4464 — прошел до конца, но страница результата пустая.

Linux m 2.6.29-zen1-home1 #6 SMP PREEMPT Sun Jun 21 20:35:42 MSD 2009 i686 Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
CFLAGS="-O2 -march=native -pipe -msse3 -fomit-frame-pointer -funroll-loops -fforce-addr -ftracer -finline-functions -fexpensive-optimizations -freorder-blocks -ftree-vectorize -mmmx -msse -msse2"
–4
rukeba #
забыли про эксплорер совсем :)
0
miga #
Довольно забавно наблюдать, как нос-в-нос идут три разных сборки фаерфокса — очень наглядное представление сферического процента прироста производительности в вакууме при «оптимизированной сборке под себя» :)
0
TheShade #
Надо понимать, что от производительности Javascript-овского компилятора производительность порождённого кода зависит очень слабо :) На самом деле, я удивлён, что прирост вообще есть, но он на грани доверительных интервалов. Если взять какой-нибудь тест, который нагружал конкретно нативную Firefox-овскую часть (типа рендеринга страниц), то прирост должен был быть больше и очевиднее.
НЛО прилетело и опубликовало эту надпись здесь
+1
non7top #
«оптимизированная сборка под себя» — это легенда противников генту
0
ScREW #
Я как раз сейчас занимаюсь разработкой небольшого RIA на ExtJS, и ждал выхода FF 3.5 с нетерпением. И к сожалению, не могу сказать, что мои надежды оправдались… :( Под ОС Linux (моя рабочая машина) я вообще не заметил разницы (конкретно в разрабатываемом мной приложении). Надо будет собрать Chrome из исходников…
0
TheShade #
Не надо собирать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.