Czy 64-bitowy Chrome jest rzeczywiście szybszy? Sprawdziliśmy to!

Google w minionym tygodniu chwalił się rozpoczęciem testów beta 64-bitowej wersji Chrome. Przeglądarka z numerkiem 37 ma na tym polu przynieść pewną rewolucję, która przełoży się na poprawę wydajności i bezpieczeństwa. O ile z tym ostatnim trudno polemizować, pierwszą obietnicę można zweryfikować, co też uczyniłem.

Gwoli ścisłości, nie jestem "benchmarkowym oszołomem" i wychodzę z założenia, że często wykresy nie mają faktycznego przełożenia na szybkość pracy danego sprzętu czy programu. Doskonale widać to w segmencie urządzeń mobilnych z Androidem, gdzie podmiana kernela na inny, bardziej dopracowany i zoptymalizowany przez "magików" z forum XDA daje solidnego kopa w działaniu smartfona/tabletu, a jednocześnie często odbija się czkawką w AnTuTu czy innych programach testujących wydajność. Czasem jednak wykorzystanie tego typu rozwiązań pozwala w łatwy sposób porównać ze sobą kilka urządzeń czy też programów. Spędziłem zatem upojny niedzielny wieczór z Excelem, by przekonać się, czy 64-bitowy Chrome faktycznie będzie rewolucją na polu wydajności.

Moja metodologia nie była zbyt skomplikowana. Wziąłem kilka popularnych benchmarków ściągnąłem dwie wersje przeglądarki Chrome - stabilną z numerem 36 oraz testową 37 ze wsparciem dla architektury 64-bitowej. Testy przeprowadzałem naprzemiennie, a więc nie wykonałem najpierw pięciu benchmarków za pomocą SunSpidera w wersji 36, a następnie pięciu w wydaniu 37, tylko dokonywałem żonglerki. Po każdym teście cache było czyszczone, a program uruchamiany ponownie. Dla każdego programu otrzymałem po pięć wyników (dla SunSpidera siedem), z których wykluczyłem najmniejszy oraz największy. Z pozostałych obliczyłem średnią, która następnie została wykorzystana do stworzenia wykresów.

Czytaj dalej poniżej

Chrome 36 z usprawnionymi powiadomieniami i nową stroną incognito stabilny Tomasz Popielarczyk

Chrome zabija baterię w twoim laptopie i spowalnia go Filip Żyro

Mój test ma jedną (brzmi dość nieskromnie, wiem) zasadniczą wadę. Wszystkie testy przeprowadzałem na łączu 0,5 Mb/s. Z perspektywy mojego celu, czyli porównania obu programów nie ma to większego znaczenia, bo warunki dla nich były identyczne. Nie zalecam jednak wykorzystywania tych wyników do porównywania Chrome z Firefoksem czy Operą (no, chyba że też dysponujecie łączem 512 Kb/s - ja przez weekend byłem na nie skazany). Wszystkie czynności były też wykonywane na nie najnowszym, bo trzyletnim sprzęcie - laptopie Dell Vostro z Intel Core i5-2520M (Sandy Bridge!), 8 GB RAM-u DDR3 1333 MHz, grafiką AMD Radeon HD 6630 (podkręconą do HD 6650) oraz dyskiem SSD Transcend 720 o pojemności 128 GB.

Testy, testy, testy...

Na pierwszy ogień poszedł Sunspider 1.0.2, czyli najpopularniejszy benchmark, który sprawdza wydajność przeglądarki pod kątem przetwarzania kodu JavaScript. Co prawda Google nic nie wspominał o tym, że Chrome 37 dzięki wsparciu dla 64-bitów przyśpieszy na tym polu, ale nie zaszkodziło sprawdzić. Wyniki pokazały, że beta radzi sobie zauważalnie gorzej. Nie jest to może różnica na tyle duża, aby okrzyknąć ją regresem, ale przeglądarka zwolniła. Notujemy zatem punkcik przy Chrome 36.

Google V8 benchmark to kolejne dość popularne narzędzie testujące przeglądarki. Jego rola również ogranicza się do silnika JavaScript. W przeszłości dość często pojawiały się zarzuty, że faworyzuje programy oparte na silniku WebKit (czy też Blink, jeśli przełożymy to na współczesność). Ku mojemu zaskoczeniu okazało się, że stabilne wydanie z numerkiem 36 okazało się minimalnie szybsze. Jest to jednak różnica na granicy błędy statystycznego, więc trudno wyciągać jakiekolwiek wnioski.

Octane to benchmark wywodzący się z opisywanego wyżej V8. Część testów wchodzących w jego skład pokrywa się z poprzednikiem, ale oprócz nich dysponuje również szeregiem innych skryptów sprawdzających wydajność przeglądarki podczas przetwarzania kodu JavaScript. On również wskazał na przewagę Chrome 36 i tutaj różnica była już zauważalnie większa. Tym samym stabilne, 32-bitowe wydanie wysunęło się na prowadzenie.

Opracowany przez firmę Rightware Browsermark to narzędzie sprawdzające wydajność przeglądarki na wielu polach. Test zaczyna się od wykonania kilku generowanych przez CSS animacji - 2D oraz 3D. Potem dochodzą do tego skalowalne elementy oraz grafiki wektorowe SVG. na sam koniec jest natomiast testowana ogólna szybkość wczytywania stron. To test komplementarny, który bada wydajność przeglądarki na wielu płaszczyznach. Lepiej wypadła tutaj 64-bitowa wersja Chrome. Warto jednak zauważyć, że różnica znów nie jest duża.

Na sam koniec zostawiłem aplikację Peacekeeper od znanej i renomowanej firmy Futuremark (to ci od 3DMarka i pochodnych). Test ten znów miał wymiar komplementarny i badał wiele różnych aspektów działania przeglądarki - od grafik wektorowych, poprzez wideo w HTML5 wykorzystujące różne kodeki, a na animacjach WebGL i skryptach DOM skończywszy. Tutaj Chrome 36 uzyskał największą przewagę nad swoim nowszym, 64-bitowym odpowiednikiem. Trudno tutaj już mówić o jakimkolwiek błędzie statystycznym. Różnica jest bardzo wyraźna.

Poniżej tabelka, na której pracowałem. Zawiera wszystkie wyniki liczbowe, które nie zostały przedstawione dostatecznie szczegółowo na wykresach (mam nauczkę na przyszłość). Czerwone pola to rezultaty, które nie zostały uwzględnione w obliczaniu średnich wyników.

Co to oznacza?

Niestety nic. Trudno wyrokować i ogłaszać regres przeglądarki Google Chrome, bo porównujemy ze sobą wersję stabilną - dopracowaną i przystosowaną do ogólnego użytku z wydaniem rozwojowym, nad którym prace ciągle jeszcze trwają. Oczywiście trudno spodziewać się, aby beta wydania 37 do swojej premiery w jakiś imponujący sposób się jeszcze rozwinęła. Jedyne jednak, że można napisać to, że na dziś jest ona w benchmarkach (podkreślam - w benchmarkach) wolniejsza od starszej wersji. Z czego to wynika? Niewykluczone, że Google ciągle udoskonala i optymalizuje 64-bitową wersję, a pierwsze efekty są po prostu niezachwycające (delikatnie mówiąc). Chrome 38, 39 i kolejne mogą pokonywać już pewne bariery, które dla architektury 32-bitowej były nie do przeskoczenia. Jestem optymistą, więc może dlatego w ten sposób sobie to tłumaczę. Jakieś pomysły?