SquirrelFish Extreme – wojnom engine’ów JavaScriptu nie ma końca

Na początku czerwca 2008 roku świat obiegła wieść o nowym, ultraszybkim engine'ie JavaScriptu, stworzonym przez deweloperów Apple'a z zespołu pracującego nad WebKitem. Otrzymał on nazwę SquirrelFish i swoją wydajnością deklasował konkurencję ze stajni Mozilli i Opery, nie mówiąc już o przeglądarce z Redmond. Jednak w drugiej połowie sierpnia br. poznaliśmy engine TraceMonkey dla Firefoksa 3.1, a później na początku września br. Google niespodziewanie przedstawiło swoją przeglądarkę Chrome z engine'em JavaScriptu V8, szybszym niż wszystkie dotychczasowe rozwiązania. I tak SquirrelFish stracił pierwszeństwo – do dzisiaj.

Deweloperzy Apple'a poinformowali właśnie, że udało im się ukończyć prace nad nową generacją swojego engine'u JavaScriptu. SquirrelFish Extreme w pierwszych testach benchmarka SunSpider po prostu zmiażdżył konkurencję – okazało się, że jest on o 36% szybszy od V8 i o 55% szybszy od TraceMonkey.

Porównanie wydajności engine'ów JavaScriptu w teście SunSpider – w liczbie ukończonych cykli na minutę dłuższe paski są lepsze (źródło: satine.org).

Jak zdołano osiągnąć tak niesamowity wynik?

Według twórców stało się to możliwe dzięki innowacyjnemu połączeniu nowych i starych sztuczek inżynierii programowania. SquirrelFish Extreme wykorzystuje łącznie cztery metody, których nie było w oryginalnym engine'ie twórców WebKita. Są to:

optymalizacja kodu bajtowego. Dzięki badaniu, które z operacji JavaScriptu wykonują się najszybciej w danym momencie, można znacznie przyspieszyć działanie całego programu. W dodatku poprawiono zestaw instrukcji kodu bajtowego, dodano instrukcje „combo”, szybszą obsługę stałych i trochę wyspecjalizowanych kodów operacyjnych dla typowych przykładów ogólnych operacji;
polimorficzne liniowe cache'owanie. Ta stara technika wywodzi się z języka Self i pozwala wykryć, kiedy obiekty mają tę samą wewnętrzną strukturę (czyli te same własności w tym samym porządku), i powiązać je z identyfikatorem struktury. Kiedy dana własność jest wywołana po raz pierwszy, engine zapisuje identyfikator w tabeli hashów i miejsce, w którym dana własność była znaleziona. Następnym razem, jeśli dany fragment kodu będzie działał na tych samych obiektach, jego identyfikator zostanie dopasowany do już istniejącego, dzięki czemu nie trzeba będzie ponownie go wywoływać;
kontekstowe wątki kompilatora JIT (Just-In-Time). Pozwalają one na konwersję kodu bajtowego na kod natywny, jeden kod operacyjny po drugim. Złożone kody operacyjne są przekładane na wywołania funkcji w bibliotece uruchomieniowej języka. Ma to dwie zalety: po pierwsze, kontrola przepływu między kodami operacyjnymi jest bezpośrednio przedstawiona procesorowi jako prosty ciąg instrukcji, po drugie zaś, wiele rozgałęzień, które formalnie zawierały się między kodami operacyjnymi, znajduje się teraz w jednej linii, dzięki czemu stają się one bardziej przewidywalne dla mechanizmu zapowiedzi rozgałęzień procesora (predyktora);
wyrażenia regularne w JIT. Po stworzeniu JIT dla podstawowej infrastruktury JavaScriptu autorom udało się stworzyć JIT dla wyrażeń regularnych – w efekcie szybkość ich przetwarzania wzrosła pięciokrotnie. Według twórców WREC, czyli WebKit Regular Expression Compiler, radzi sobie teraz z wyrażeniami regularnymi szybciej, niż ma to miejsce w wypadku takich języków, jak Python, Perl czy Ruby.

Możliwości nowego engine'u JavaScriptu od Apple'a można sprawdzić samemu, jeśli się pobierze kod źródłowy bądź skompilowaną wersję ze strony nightly.webkit.org/.

źródła: WebKit.org/blog/, Satine.org

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

5 skomentuj »

Polecamy

Reklama

Komentarze

#1 bimas 2008-09-20 15:21:43 0
Jest to powód do powstawania coraz to nowszych aplikacji webowych opartych o JavaScript i AJAX.
None
#2 dAREuS^® 2008-09-20 15:43:47 0
Bimas, myślę podobnie. Już Chrome pokazało, że "obejdziemy się bez ActionScriptu" - to być może uderza w Adobe najmocniej.
None
#3 dbaj 2008-09-20 22:14:56 0
dAREuS, a ja myślę, że to zbyt odważne stwierdzenie. To jest tak jak byśmy zapomnieli o latach rozwijania wyjątkowego środowiska jakim jest Flash. Myślę, że AS będzie miał jeszcze sporo do powiedzenia. Nie po to Adobe kupiło Macromedia, żeby teraz tak łatwo oddać piłeczkę.

Programiści związani z AS wiedzą jak wiele się teraz dzieje.... A dzieje się to mimo braku adekwatnych rozwiązań w JS i AJAX.
None
#4 pablo 2008-09-20 23:19:03 0
Javascript nie dorasta flashowi do pięt, więc na pewno nie wyprze go z rynku. Znam oba, wiem co potrafią i do zwykłych stron uważam, że javascript starcza, do stron z multimediami - flash nie ma sobie równych.
None
#5 eimi^® 2008-09-21 12:41:28 0
w minionym wieku podobnie mówiono o Flashu - że nie dorasta Javie do pięt i aplety Javy są przyszłością Sieci.

Tutaj można zobaczyć (najlepiej przy wykorzystaniu Firefoksa Shirotoku beta 2), co możliwe jest za pomocą JavaScriptu, SVG i HTML5 (video, canvas).

Jeśli to się przyjmie, a nowoczesne przeglądarki będą miały szybkie engine'y (a będą) - to dominacja Flasha w dziedzinie multimediów wcale nie jest taka pewna. Zresztą.. wystarczy że Google w pewnym momencie sprawi, że Chrome będzie wyświetlało filmy z YT bez Flasha :D.
None

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.