dzisiaj przedstawiamy nowy zestaw testów benchmark JavaScript Webkit, JetStream. JetStream kodyfikuje nasz proces de facto-aby połączyć wskaźniki opóźnienia i przepustowości z mniej więcej równą wagą, i przechwytując zarówno metryki tradycyjnych stylów programowania JavaScript, jak i nowe technologie oparte na JavaScript, które uchwyciły naszą wyobraźnię. Wyniki na JetStream są dobrym wskaźnikiem wydajności, jaką użytkownicy zobaczyliby w zaawansowanych aplikacjach internetowych, takich jak gry.
Optymalizacja wydajności naszego silnika JavaScript jest priorytetem dla projektu WebKit. Przykłady niektórych usprawnień, które wprowadziliśmy w zeszłym roku, obejmują kompilację równoległą, generacyjny GC i JIT FTL. Inżynieria takich ulepszeń wymaga skupienia: staramy się priorytetowo traktować projekty o dużym wpływie, a nie budowanie i utrzymywanie złożonych optymalizacji, które przynoszą mniejsze korzyści. W ten sposób motywujemy pracę z wydajnością za pomocą benchmarków, które ilustrują rodzaje obciążeń, z którymi użytkownicy WebKit mogą się spotkać. Ta filozofia rozwoju opartego na benchmarku od dawna jest częścią WebKit.
poprzedni stan benchmarkingu JavaScript
gdy wprowadzaliśmy ulepszenia w silniku JavaScript WebKit, okazało się, że żaden pojedynczy pakiet benchmarkingu nie jest całkowicie reprezentatywny dla scenariuszy, które chcieliśmy poprawić. Podoba nam się, że JSBench mierzy wydajność kodu JavaScript na popularnych stronach internetowych, ale WebKit już radzi sobie bardzo dobrze na tym benchmarku. Lubimy SunSpider za jego pokrycie powszechnie używanych konstrukcji językowych i za to, że jego czas działania jest reprezentatywny dla czasu działania kodu w Internecie, ale nie jest odpowiedni do pomiaru szczytowej przepustowości. Podoba nam się Octane, ale za bardzo przesuwa się w drugą stronę: jest przydatny do określania maksymalnej przepustowości naszego silnika, ale nie jest wystarczająco wrażliwy na wydajność, którą najprawdopodobniej zobaczysz w typowych obciążeniach internetowych. Bagatelizuje również nowatorskie technologie JavaScript, takie jak asm.js; tylko jednym z 15 benchmarków Octane był asm.test js, a ten test ignoruje wydajność zmiennoprzecinkową.
znalezienie dobrego asm.testy JS są trudne. Mimo że Emscripten zyskuje mindshare, jego testy są długotrwałe i do niedawna brakowało uprzęży internetowej. Zbudowaliśmy więc własny asm.benchmarki js przy użyciu testów z pakietu testowego LLVM. Te testy C i C++ są używane przez programistów LLVM do śledzenia ulepszeń wydajności stosu kompilatorów clang / LLVM. Emscripten sam używa LLVM do generowania kodu JavaScript. To sprawia, że pakiet testowy LLVM jest szczególnie odpowiedni do testowania, jak dobrze silnik JavaScript obsługuje natywny kod. Kolejną zaletą naszych nowych testów jest to, że są one znacznie szybsze w uruchomieniu niż pakiet testów Emscripten.
posiadanie dobrych benchmarków JavaScript pozwala nam śmiało dążyć do ambitnych ulepszeń Webkita. Na przykład SunSpider kierował naszą jednoczesną kompilacją, podczas gdy asm.testy js i testy przepustowości Octane zmotywowały nas do pracy nad JIT FTL. Ale umożliwienie naszym testom bazowania na hodgepodge tych różnych zestawów benchmarków stało się niepraktyczne. Trudno powiedzieć współpracownikom, co powinni testować, jeśli nie ma ujednoliconego pakietu testów, który mógłby im powiedzieć, czy ich zmiana miała pożądany wpływ na wydajność. Chcemy jednego pakietu testowego, który może zgłosić jeden wynik na końcu, i chcemy, aby ten jeden wynik był reprezentatywny dla przyszłego kierunku WebKit.
projektowanie nowego pakietu Jetstream Benchmark Suite
różne komponenty WebKit wymagają różnych podejść do pomiaru wydajności. Na przykład w przypadku wydajności DOM wprowadziliśmy właśnie benchmark prędkościomierza. W niektórych przypadkach oczywiste podejście działa całkiem dobrze: na przykład wiele optymalizacji układu i renderowania może być sterowanych przez pomiar czasu ładowania strony na reprezentatywnych stronach internetowych. Ale pomiar wydajności implementacji języka programowania wymaga większej subtelności. Chcemy zwiększyć wrażliwość benchmarków na podstawowe ulepszenia silnika, ale nie tak bardzo, że tracimy perspektywę na to, jak te ulepszenia silnika grają w prawdziwych witrynach internetowych. Chcemy zminimalizować szanse, że hałas systemowy zmyje nasze pomiary, ale za każdym razem, gdy obciążenie pracą jest z natury podatne na hałas, chcemy, aby pokazano to w modelu benchmark. Chcemy, aby nasze benchmarki reprezentowały wierne przybliżenie obciążeń, na których użytkownicy WebKit prawdopodobnie będą dbać.
JetStream łączy różne benchmarki JavaScript, obejmujące wiele zaawansowanych obciążeń i technik programowania, i zgłasza pojedynczy wynik, który równoważy je za pomocą średniej geometrycznej. Każdy test jest przeprowadzany trzy razy, a wyniki są zgłaszane z 95% przedziałami ufności. Każdy benchmark mierzy różne obciążenie pracą, a żadna pojedyncza technika optymalizacji nie jest wystarczająca, aby przyspieszyć wszystkie benchmarki. Niektóre benchmarki wykazują kompromisy, a agresywna lub wyspecjalizowana Optymalizacja dla jednego benchmarka może spowodować, że inny benchmark będzie wolniejszy. Wykazanie kompromisów jest kluczowe dla naszej pracy. Jak omówiłem w moim poprzednim poście na temat naszego nowego kompilatora JIT, WebKit próbuje dynamicznie dostosować się do obciążenia za pomocą różnych warstw wykonawczych. Ale to nigdy nie jest idealne. Na przykład, podczas gdy nasz nowy kompilator FTL JIT daje nam fantastyczne przyspieszenie w testach szczytowej przepustowości, powoduje on niewielkie regresje w niektórych testach przyspieszania. Nowe optymalizacje dla zaawansowanych wersji językowych często napotykają na takie kompromisy, a naszym celem w JetStream jest posiadanie benchmarka, który informuje nas o kompromisy, które robimy.
JetStream zawiera benchmarki z pakietów SunSpider 1.0.2 I Octane 2 JavaScript. Zawiera również benchmarki z LLVM compiler open source project, skompilowane do JavaScript przy użyciu Emscripten 1.13. Zawiera również benchmark oparty na Hashmapie projektu Apache Harmony open source, ręcznie tłumaczonym na JavaScript. Więcej informacji na temat benchmarków zawartych w JetStream można znaleźć na stronie Jetstream in Depth.
cieszymy się, że możemy wprowadzić ten nowy benchmark. Aby go uruchomić, wystarczy odwiedzić browserbench.org/JetStream. możesz zgłaszać błędy w porównaniu z benchmarkiem za pomocą systemu zarządzania błędami WebKit w komponencie narzędzia / testy.
