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

JavaScript stoi w centrum zainteresowań Mozilli: od wydajnościuruchamiania kodu w tym jedynym dostępnym dla współczesnychprzeglądarek języku programowania zależy powodzenie planówprzekształcenia Webu w otwartą platformę dla aplikacji. Przeglądarkajako uniwersalna maszyna uruchomieniowa, nie potrzebująca żadnychwtyczek do odtwarzania dostępnych po HTTP treści stała się idée fixeproducenta Firefoksa, który tworzy coraz bardziej wyrafinowanerozwiązania techniczne, by udowodnić, że można, że pisane wJavaScripcie aplikacje mogą dorównać w wydajności klasycznymaplikacjom desktopowym. Dzisiaj na łamach bloga Mozilli, Alon Zakai,twórca skrośnego kompilatora Emscripten, donosio 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 nietestuje 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 tobenchmarki, które skompilowano za pomocą kompilatora Emscripten z C,ale nie do JavaScriptu, lecz do bardzo szczególnego podzbioruJavaScriptu, nazwanego asm.js.Przypomnijmy: asm.js to JavaScript, z którego usunięto wszystkiespowalniają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 maszynowemuniż językom wysokiego poziomu, jest uruchamiany na specjalnie podasm.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łconychprzez Emscripten aplikacji wydajność tylko dwukrotnie niższą od kodunatywnego (niestety nie wiemy, jakie optymalizacje zastosowanowówczas do generowania tego „kodu natywnego”). Było tojednak 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 przyspieszanieJavaScriptu. Zakai wskazuje tutaj m.in. na zoptymalizowanieniektórych operacji zmiennoprzecinkowych, tak by były przeprowadzanez użyciem arytmetyki float32 (pojedynczej precyzji), zamiastwykorzystywanej 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órychwykorzystanie instrukcji float32 przez kompilator będzie bezpieczne,a przy tym znacznie wydajniejsze od korzystania z instrukcji float64.[img=asm1.5b]Jak na razie wykorzystanie generowania kodu z float32 w emscriptenjest domyślnie wyłączone (za wzrost wydajności w niektórychscenariuszach płaci się zwiększeniem rozmiaru kodu w związku zkoniecznością dodania do niego specjalnych metod), ale przedstawioneprzez Zakaiego wyniki benchmarków pokazują, że Mozilla jest na dobrejdrodze. W jednym z testów (box2d) kod w JavaScripcie okazał się nawetszybszy od kodu natywnego, wygenerowanego przez kompilator clang 3.2(choć kod z gcc wciąż był szybszy). Najbardziej spektakularne wynikioptymalizacja float32 przyniosła dla benchmarka skinning, pozwalającna przyspieszenie o nawet 30% względem standardowej wydajnościFirefoksa, choć w dwóch innych benchmarkach przyniosła niewielkie,kilkuprocentowe spowolnienie.Twórca Emscriptena przekonany jest, że to nie jest koniec tego, comożna osiągnąć zarówno w samym kompilatorze, jak i silnikachskryptowych, więc możemy się spodziewać dalszego wzrostu wydajnościaplikacji webowych w Firefoksie i Firefox OS-ie. To kwestiaszczególnie paląca dla tego ostatniego – deweloperzy aplikacjimobilnych 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ł naswoim blogu), ale nie sposób zaprzeczyć, że ich wydajność pozostawiasporo do życzenia. Działają one (na porównywalnym sprzęcie) wolniejnie tylko od aplikacji w kodzie natywnym, ale też od androidowychaplikacji w pośrednim kodzie bajtowym, wykonywanych przez maszynęwirtualną.To ostatnie nie powinno nikogo dziwić – powolna Java tohistoria z lat 90, a współczesne maszyny wirtualne Javy (w tym iDalvik) 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łysię praktycznie znikome (zainteresowani mogąsięgnąć do poświęconej tej kwestii pracy Andreasa Ulvesanda iDaniela Erikssona pt. Native Code on Android). A skoro udało się to osiągnąć dla Javy, nie jest wykluczone, żebędzie można to osiągnąć dla JavaScriptu.