r   e   k   l   a   m   a
r   e   k   l   a   m   a

Mozilla chwali się szybszym asm.js. JavaScript będzie nową Javą?

Strona główna AktualnościOPROGRAMOWANIE

JavaScript stoi w centrum zainteresowań Mozilli: od wydajności uruchamiania kodu w tym jedynym dostępnym dla współczesnych przeglądarek języku programowania zależy powodzenie planów przekształcenia Webu w otwartą platformę dla aplikacji. Przeglądarka jako uniwersalna maszyna uruchomieniowa, nie potrzebująca żadnych wtyczek do odtwarzania dostępnych po HTTP treści stała się idée fixe producenta Firefoksa, który tworzy coraz bardziej wyrafinowane rozwiązania techniczne, by udowodnić, że można, że pisane w JavaScripcie aplikacje mogą dorównać w wydajności klasycznym aplikacjom desktopowym. Dzisiaj na łamach bloga Mozilli, Alon Zakai, twórca skrośnego kompilatora Emscripten, donosi o osiągnięciu przełomu w tych staraniach: kod w JavaScripcie ma być już tylko 1,5 raza wolniejszy od „kodu natywnego”.

Aby osiągnąć taką wydajność, nie obyło się bez sztuczek. Zakai nie testuje aplikacji pisanych w JavaScripcie „odręcznie”, nie testuje też aplikacji pisanych w jakimś języku wyższego poziomu (np. Javie) i maszynowo konwertowanych do JavaScriptu za pomocą takich narzędzi jak np. Google Web Toolkit. Testowane aplikacje to benchmarki, które skompilowano za pomocą kompilatora Emscripten z C, ale nie do JavaScriptu, lecz do bardzo szczególnego podzbioru JavaScriptu, nazwanego asm.js.

Przypomnijmy: asm.js to JavaScript, z którego usunięto wszystkie spowalniające ten język konstrukcje. Mamy tu statycznie typowany kod, dużą binarną stertę, arytmetykę stało- i zmiennoprzecinkową, wskaźniki i definicje funkcji. Kod taki, bliższy językowi maszynowemu niż językom wysokiego poziomu, jest uruchamiany na specjalnie pod asm.js zoptymalizowanych silnikach skryptowych.

Firefox zapewnia wsparcie dla asm.js od wersji 22 przeglądarki – i wtedy już udało się uzyskać dla niektórych tak przekształconych przez Emscripten aplikacji wydajność tylko dwukrotnie niższą od kodu natywnego (niestety nie wiemy, jakie optymalizacje zastosowano wówczas do generowania tego „kodu natywnego”). Było to jednak wielkie osiągnięcie – bez tych optymalizacji wydajność kodu w JavaScripcie była pięcio-, a nawet sześciokrotnie niższa.

Od tamtej pory ulepszenia zarówno po stronie silnika skryptowego, jak i samego Emscripten, pozwoliły na dalsze przyspieszanie JavaScriptu. Zakai wskazuje tutaj m.in. na zoptymalizowanie niektórych operacji zmiennoprzecinkowych, tak by były przeprowadzane z użyciem arytmetyki float32 (pojedynczej precyzji), zamiast wykorzystywanej do tej pory arytmetyki float64 (podwójnej precyzji – tak jak wskazuje to standard IEEE754). Słowem-kluczem jest tu „niektórych” – da się wskazać warunki, przy których wykorzystanie instrukcji float32 przez kompilator będzie bezpieczne, a przy tym znacznie wydajniejsze od korzystania z instrukcji float64.

Jak na razie wykorzystanie generowania kodu z float32 w emscripten jest domyślnie wyłączone (za wzrost wydajności w niektórych scenariuszach płaci się zwiększeniem rozmiaru kodu w związku z koniecznością dodania do niego specjalnych metod), ale przedstawione przez Zakaiego wyniki benchmarków pokazują, że Mozilla jest na dobrej drodze. W jednym z testów (box2d) kod w JavaScripcie okazał się nawet szybszy od kodu natywnego, wygenerowanego przez kompilator clang 3.2 (choć kod z gcc wciąż był szybszy). Najbardziej spektakularne wyniki optymalizacja float32 przyniosła dla benchmarka skinning, pozwalając na przyspieszenie o nawet 30% względem standardowej wydajności Firefoksa, choć w dwóch innych benchmarkach przyniosła niewielkie, kilkuprocentowe spowolnienie.

Twórca Emscriptena przekonany jest, że to nie jest koniec tego, co można osiągnąć zarówno w samym kompilatorze, jak i silnikach skryptowych, więc możemy się spodziewać dalszego wzrostu wydajności aplikacji webowych w Firefoksie i Firefox OS-ie. To kwestia szczególnie paląca dla tego ostatniego – deweloperzy aplikacji mobilnych są w wypadku systemu Mozilli skazani na JavaScript. Nie żeby budowanie udanych aplikacji w tej technologii było niemożliwe (przekonać się o tym możecie z wyznań deweloperów, które producent Firefoksa właśnie opublikował na swoim blogu), ale nie sposób zaprzeczyć, że ich wydajność pozostawia sporo do życzenia. Działają one (na porównywalnym sprzęcie) wolniej nie tylko od aplikacji w kodzie natywnym, ale też od androidowych aplikacji w pośrednim kodzie bajtowym, wykonywanych przez maszynę wirtualną.

To ostatnie nie powinno nikogo dziwić – powolna Java to historia z lat 90, a współczesne maszyny wirtualne Javy (w tym i Dalvik) są wysoce zoptymalizowanymi, wykorzystującymi specyfikę sprzętu konstrukcjami. Odkąd w Androidzie Dalvik doczekał się kompilatora JIT, różnice między wydajnością kodu w C i Javie stały się praktycznie znikome (zainteresowani mogą sięgnąć do poświęconej tej kwestii pracy Andreasa Ulvesanda i Daniela Erikssona pt. Native Code on Android).

A skoro udało się to osiągnąć dla Javy, nie jest wykluczone, że będzie można to osiągnąć dla JavaScriptu.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.