Safari szybsze niż światło: kompilator LLVM w silniku przeglądarki Apple'a

Kompilatory Just-In-Time (JIT) w silnikach skryptowychprzeglądarek to już nic nowego – pierwszy pojawił się wFirefoksie w czasach, gdy Chrome było jeszcze na deskachkreślarskich. Pozwalają one na przekształcenie kodu w JavaScripciena kod maszynowy już w trakcie jego uruchamiania, stosując rozmaiteoptymalizacje, by kod ten był wykonywany tak szybko, jak to możliwe.W miarę rozwoju kompilatorów JIT zaczęły one dorównywaćzłożonością tradycyjnym kompilatorom języków wysokiego poziomuAhead-Of-Time (AOT). Jednocześnie rozwój aplikacji webowychdoprowadził do tego, że zaczęły one dorównywać w złożonościaplikacjom desktopowym.

Programiści z Cupertino, pracując nad silnikiem WebKit, używanymw przeglądarkach Safari, starają się wprowadzać do kompilatoraJIT JavaScriptu optymalizacje, które będą efektywne zarówno dladynamicznych skryptów, które są szybko pobierane i uruchamiane wkrótkim czasie, jak i dla dużych partii kodu, których fragmentywykonywane są przez długi czas – np. silniki gier czy kodeki. Wtrakcie tej pracy zauważyli, że coraz częściej wynajdują kołona nowo, odtwarzając logikę stosowaną już od dziesięcioleci wkompilatorach AOT. Spostrzeżenie zaowocowało ciekawympomysłem: a co, gdyby wykorzystać w silniku przeglądarkinormalny, zaawansowany kompilator?

To co było tylko eksperymentem, zaowocowało przełomemw WebKicie. Do tej pory silnik skryptowy Apple'a działał wtrzech etapach, zapewniających trzy poziomy wydajności uruchamianymna nim skryptom. Pierwszy z nich to interpreter LLInt, w którymskrypty uruchamiane były bez jakiejkolwiek kompilacji,natychmiastowo. Jeśli w skrypcie dana funkcja wywoływana byławięcej niż sześć razy, albo jeśli dana pętla wykonywana byłaczęściej niż sto razy, to wówczas kod trafiał do prostegokompilatora JIT (Baseline JIT), który bez jakichś szczególnychoptymalizacji zwracał dla niej kod maszynowy, i tak działający conajmniej dziesięć razy szybciej, niż kod interpretowany. Jeślijednak dana funkcja była wywoływana więcej niż 66 razy, lub pętlawykonywana więcej niż tysiąc razy, to trafiała do zaawansowanegokompilatora JIT (Data Flow Graph JIT, DFL), który stosując różneoptymalizacje zwracał kod około trzykrotnie szybciej wykonywany,niż to, co był w stanie zwrócić podstawowy kompilator.

Do tych trzech poziomów doszedł teraz poziom czwarty, który wzałożeniu ma zapewnić taki poziom optymalizacji, jaki zapewniająkompilatory C czy C++. Ludzie Apple'a nazwali go FTL, co ma byćskrótem od Fourth Tier LLVM („LLVM czwartego poziomu”), aleskojarzenia z Faster-Than-Light („szybciej-niż-światło”) sąnieuchronne. Poziom czwarty powiela do pewnego stopnia ścieżkęoptymalizacji zaawansowanego kompilatora JIT, ale jak widać naponiższym schemacie, po fazie wstępnych optymalizacji, zamiasturuchomić generator kodu maszynowego, przekształca jużzoptymalizowane funkcje JavaScriptu do postaci SSA (single staticassignment), w której każdej zmiennej wartość przypisuje siętylko raz, następnie przeprowadza dodatkowe optymalizacje, bywreszcie całość przekazać do kompilatora LLVM.

Jak wyjaśniają programiści WebKitu, LLVM został wybrany zewzględu na zaawansowany, dojrzały do zastosowań produkcyjnychpotok optymalizacyjny, w którym stosowane są tak pożądanemechanizmy jak zaawansowana alokacja rejestrów, zliczanie globalnychwartości i efektywny wybierak instrukcji. Pewnie nie bez znaczeniabyła też przyjazna dla biznesu otwarta licencja LLVM, tzw. NCSAOpen Source License, która jest kombinacją licencji BSD i MIT/X11.Oprogramowanie wydane na takiej licencji można bez ograniczeń idodatkowych obowiązków stosować w produktach komercyjnych. Minusemzastosowania LLVM jest jego relatywna powolność – kod, któryprodukuje jest bardzo szybki, ale sam proces kompilacji już takiszybki nie jest. By ograniczyć do minimum spowolnienia wywołanekombinacją, czwarty poziom kompilacji w WebKicie uruchamiany jesttylko dla funkcji, które wywoływane są naprawdę często, lubktórych uruchomienie zajmuje ponad 10 ms. Dodatkowo uruchamia sięgo w oddzielnym wątku, by aplikacja nie musiała czekać, w tymczasie stosując kod wygenerowany na poziomie trzecim.

Pierwsze benchmarki pokazują, że było to bardzo udaneposunięcie. Dla skryptów napisanych w stworzonym przez Mozillępodzbiorze JavaScriptu asm.js, kod wykonywany przez FTL jest średnio35% szybszy niż kod z DFL. Deweloperzy Apple'a podkreślają, że todopiero początek optymalizacji, trzeba teraz powiększyć zbióroperacji JavaScriptu, które można kompilować FTL-em.

Efekty tej pracy już trafiły do najnowszych kompilacji WebKitu,dostępnych na stronie nightly.webkit.org.Niebawem pojawią się w stabilnych wersjach Safari, zarówno wwersji desktopowej tej przeglądarki, jak i wersji mobilnej dlaiOS-a.