Wczoraj Mozilla ogłosiła prace nad silnikiem TraceMonkey. TM jest modyfikacją aktualnego silnika Gecko – SpiderMonkey, do którego dodana została opracowana przez pracowników Uniwersytetu Kalifornijskiego implementacja algorytmu JIT. Nie jest to może żadna czarna magia, po prostu opóźnienie wykonywania skryptów JS (każdy kto pracował z JS wie, jakie ograniczenia wydajności JS nakłada – nikt raczej nie pokusiłby się o tworzenie silników graficznych 3D w JS) jako interpretowanych jest tak duża, że okazało się, iż opłaca się skompilować wstępnie kawałki kodu JS i w przypadku występowania powtarzających się procedur odpalać skompilowane fragementy zamiast interpretowania kodu na bieżąco.
Efekty są bardzo wydatne.
Każdy kto śledzi planetę Mozilli widział już wykresy Brendana, Shavera i Schrepa. Ja wykonałem małe testy na benchmarku Dromaeo autorstwa niezrównanego Johna Resiga.
Wykonałem dwa testy – w Fx 3.0.1 i dzisiejszej kompilacji nocnej z włączonym JIT dla treści stron.
Wynik dla Fx 3.0.1, Wynik dla Minefield trunk i wynik porównania dwóch. Przyspieszyć o kolejne 46%? Nieźle… co? 😉
Najlepszą informacją w tym wszystkim jest to, że Brendan twierdzi, że JIT powinien być szybszy w dokładnie każdym teście. Jeśli gdzieś nie jest, jest to błąd i będą to teraz poprawiać… Całość implementacji zajęła 60 dni i jest to wersja bardzo wstępna, najbliższe miesiące powinny przynieść kolejne przyspieszenia wraz z optymalizacją nowych możliwości.
Co z Tamarinem? Tamarin to znacznie bardziej poważny eksperyment, wymagający dużego nakładu pracy. Ma być on podstawą silnika ActionScript, który zastąpi obecny w platformie Mozilla 2 (i w efekcie w Firefoksie 4).
Obecnie prace nad nim trwają w osobnym repozytorium na hg.mozilla.org, i zostanie on włączony do mozilla-central prawdopodobnie po wydaniu Fx3.1. Tamarin ma być oczywiście znowu, znacznie szybszy od TraceMonkey (gdyż będzie korzystał z jego dobrodziejstw i dodawał kolejne), będzie też pierwszą implementacją języka JavaScript 2.0 (który dla mnie jest przede wszystkim pokornym wzięciem największych dobrodziejstw Pythona:) ) ale można go już dziś przetestować kompilując tamarin-central.
Kolcami tej róży są problemy z debuggerami. JIT sprawia, że cały proces interpretacji przestaje być deterministyczny i nie za bardzo wiadomo jak to obejść. Na razie przy włączonym Venkmanie, Gecko wyłącza JIT, ale nie jest to optymalne rozwiązanie i będzie trzeba poczekać, aż Gijs wróci z wakacji i podejmie decyzje co dalej z Venkmanem…
Jeśli ktoś chce włączyć JIT, to może to zrobić na dwóch poziomach – dla stron i dla samego Firefoksa (about:config i szukaj “jit”). Włączenie dla Firefoksa oczywiście znacznie poprawia jego wydajność (duże części Fx napisane są w JS), ale jest w tym momencie dość ryzykowne. Natomiast dla stron jest dość stabilnie (zanotowałem kilka wywaleń w Gmailu i Facebooku tylko) i z każdym dniem będzie lepiej 🙂
Docelowo, w ActionMonkey i Mozilla 2, celem Mozilli jest aby jak najwięcej kodu było pisanego w JS, a wydajność JS była porównywalna z kodem kompilowanym (C++)… Coś co wydawało się niemożliwe, nie tylko stało się realne, ale jest aktualnie celem programistów w projekcie Mozilla. Mam nadzieję, że się uda 🙂
7 replies on “TraceMonkey a Tamarin”
ECMAScript 4 vel JavaScript 2 został wyrzucony na śmietnik przez komitet ECMA TC-39.
Rozwiązanie to od dawna forsował pewien Wiodący Producent Oprogramowania ze stanu Waszyngton. Pewna fundacja z Mt. View do spółki z taką jedną firmą z Cupertino i jakimiś Norwegami wolały rozbudować JS o różne nowe rzeczy, które ułatwiłyby życie webdeveloperem, ale w końcu uległy i ECMAScriptu 4/JavaScriptu 2 nie ma.
Wiodący Producent chciał bugfix-release’a, i takim będzie ECMAScript 3.1, poprawiający błędy w specyfikacji ES3 i dodający niektóre ficzery już zaimplementowane przez tych z Mt. View, Cupertino i Norwegii – ale bez przesady.
Dalszy rozwój ES ma zapewnić tzw. ECMAScript Harmony, który wciąż jednak nie będzie tak ambitnym zamierzeniem, jakim miał być niedoszły ES4. Bez pakietów i przestrzeni nazw, co w erze “mashupów” jest bardzo przykre, bo w dalszym ciągu nie będziesz miał podczas korzystania jednocześnie np. z API Yahoo i Wypaśnego Skryptu Wujka Cześka gwarancji, że taki WSWCz nie nadpisze ci globalnego obiektu YAHOO. Albo odwrotnie*.
Oficjalnie Mozilla i sam Brendan Eich mówią, że to fajnie, że uzyskaliśmy konsensus, ale dla mnie to jest robienie dobrej miny do złej gry. ActionScript i JavaScript się teraz rozejdą całkowicie, bo Adobe nie zamierza wycofać się tego, co z śp. ES4 już w AS zaimplementował.
*) to nie jest wcale wydumane – choćby takie głupie wstawki Gemiusa robią burdel w globalnej przestrzeni nazw różnymi zmiennymi gt_*, zamiast zrobić sobie jeden normalny obiekt.
Pamiętam Mozillę, Netscape od dość dawna (rok 98) ale takiego przyspieszenia z wersji na wersję co z 2* do 3.0*, a zapowiada się także na 3.1* i 4.0* to jeszcze nie doświadczyłem 🙂 Gdy czytałem o budowie Mozilli to nie sądziłem, że może to być takie szybkie, małe, niezasobożerne. Jak coraz częściej widać myliłem się, i obym mylił się dalej. Odzyskuję wiarę.
mazdac: gandalf pisze o JS, ale niezłe bajery wchodzą też do Gecko jeśli chodzi o CSS, choćby długo oczekiwany text-shadow. 😉
Szykuję od dłuższego czasu blogonotkę na ten temat, ale jakoś ciągle mi brakuje czasu… :/
marcoos: rozumiem, ale większa wydajność silnika js wpłynie na szybszą pracę samego programu (interfejs o ile się nie mylę oparty jest o xul, css i js właśnie)
mazdac: odpal nightly 3.1, wpisz “about:config”, zgódź się na warning, filtruj przez “jit”, zaznacz obie zmienne na TRUE i restart przgladarki…
Jak dla mnie to wyrazne przyspieszenie 🙂
morphos: zrobiłem to już wczoraj i faktycznie przyspieszenie jest widoczne, ba nawet znalazłem i zgłosiłem błąd, no chyba, że znalazł go ktoś wcześniej (benchmark sunspider, wywala się na kolejnym teście po “accesing binary tree”).
[…] public links >> actionmonkey TraceMonkey a Tamarin Saved by davinwp on Fri 24-10-2008 Firefox 4: pohľad dovnútra Saved by kennlouis on Fri […]