i dag introducerer vi en ny JavaScript benchmark test suite, JetStream. JetStream kodificerer, hvad vores De facto — proces har været-at kombinere latens-og gennemløbsbenchmarks med omtrent lige stor vægtning, og fange begge målinger af traditionelle JavaScript-programmeringsstile såvel som nye JavaScript-baserede teknologier, der har fanget vores fantasi. Resultater på JetStream er en god indikator for den ydeevne, brugerne vil se i avancerede internetapplikationer som spil.
optimering af vores JavaScript-motor er en høj prioritet for projektet. Eksempler på nogle af de forbedringer, vi introducerede i det sidste år, inkluderer samtidig kompilering, generations GC, og FTL JIT. At konstruere sådanne forbedringer kræver fokus: vi forsøger at prioritere projekter med stor effekt frem for at opbygge og vedligeholde komplekse optimeringer, der har mindre fordele. Således motiverer vi præstationsarbejde med benchmarks, der illustrerer den slags arbejdsbyrde, som brugerne sandsynligvis vil støde på. Denne filosofi om benchmark-drevet udvikling har længe været en del af
den tidligere tilstand af JavaScript-Benchmarking
da vi foretog forbedringer af JavaScript-motoren, fandt vi, at ingen enkelt benchmark-pakke var helt repræsentativ for de scenarier, som vi ønskede at forbedre. Vi kan godt lide, at JSBench måler udførelsen af JavaScript-kode på populære hjemmesider, men det gør det allerede meget godt på dette benchmark. Vi kan godt lide SunSpider for sin dækning af almindeligt anvendte sprogkonstruktioner og for det faktum, at dens driftstid er repræsentativ for køretiden for kode på nettet, men det kommer til kort for måling af spidsbelastning. Vi kan godt lide oktan, men det skæver for langt i den anden retning: det er nyttigt til at bestemme vores Motors maksimale gennemstrømning, men er ikke følsom nok til den ydelse, du mest sandsynligt vil se på typiske arbejdsbelastninger på nettet. Det bagatelliserer også nye JavaScript-teknologier som asm.js; kun en af Octans 15 benchmarks var en asm.js test, og denne test ignorerer flydende punkt ydeevne.
find god asm.JS benchmarks er vanskelige. Selvom Emscripten vinder mindshare, er dens tests langvarige og indtil for nylig manglede en netsele. Så vi byggede vores egen asm.JS benchmarks ved hjælp af tests fra LLVM test suite. Disse C-og C++ – tests bruges af LLVM-udviklere til at spore præstationsforbedringer af clang/LLVM compiler stack. Emscripten selv bruger LLVM til at generere JavaScript-kode. Dette gør LLVM test suite særligt egnet til at teste, hvor godt en JavaScript-motor håndterer native kode. En anden fordel ved vores nye test er, at de er meget hurtigere at køre end Emscripten test suite.
at have gode JavaScript-benchmarks giver os mulighed for med sikkerhed at forfølge ambitiøse forbedringer. For eksempel, SunSpider guidede vores samtidige kompileringsarbejde, mens asm.js-test og Oktans gennemløbstest motiverede vores arbejde med FTL JIT. Men at lade vores test være baseret på en hodgepodge af disse forskellige benchmark-suiter er blevet upraktisk. Det er svært at fortælle bidragydere, hvad de skal teste, hvis der ikke er nogen samlet testpakke, der kan fortælle dem, om deres ændring havde den ønskede effekt på ydeevnen. Vi vil have en test suite, der kan rapportere en score i sidste ende, og vi ønsker, at denne ene score skal være repræsentativ for den fremtidige retning.
design af den nye Jetstream Benchmark Suite
forskellige komponenter kræver forskellige tilgange til måling af ydeevne. For eksempel til DOM-ydelse introducerede vi netop Speedometer-benchmarket. I nogle tilfælde, den åbenlyse tilgang fungerer ret godt: for eksempel kan mange layout-og gengivelsesoptimeringer drives ved at måle sideindlæsningstid på repræsentative hjemmesider. Men måling af ydeevnen for en implementering af et programmeringssprog kræver mere subtilitet. Vi ønsker at øge benchmarks følsomhed over for core motor forbedringer, men ikke så meget, at vi mister perspektiv på, hvordan disse motor forbedringer spille ud i reelle hjemmesider. Vi ønsker at minimere mulighederne for systemstøj til at smide vores målinger, men når som helst en arbejdsbyrde er iboende udsat for støj, ønsker vi et benchmark for at vise dette. Vi ønsker, at vores benchmarks skal repræsentere en high-fidelity-tilnærmelse af de arbejdsbelastninger, som brugerne sandsynligvis vil bekymre sig om.
JetStream kombinerer en række JavaScript-benchmarks, der dækker en række avancerede arbejdsbelastninger og programmeringsteknikker og rapporterer en enkelt score, der afbalancerer dem ved hjælp af et geometrisk gennemsnit. Hver test køres tre gange, og scoringer rapporteres med 95% konfidensintervaller. Hvert benchmark måler en særskilt arbejdsbyrde, og ingen enkelt optimeringsteknik er tilstrækkelig til at fremskynde alle benchmarks. Nogle benchmarks viser afvejninger, og aggressiv eller specialiseret optimering for et benchmark kan gøre et andet benchmark langsommere. Demonstration af afvejninger er afgørende for vores arbejde. Som diskuteret i mit tidligere indlæg om vores nye JIT-kompilator forsøger vi dynamisk at tilpasse sig arbejdsbyrden ved hjælp af forskellige udførelsesniveauer. Men dette er aldrig perfekt. For eksempel, mens vores nye FTL JIT compiler giver os fantastiske speed-ups på peak throughput tests, forårsager det små regressioner i nogle ramp-up tests. Nye optimeringer til avancerede sprogkørsler løber ofte ind i sådanne afvejninger, og vores mål med JetStream er at have et benchmark, der informerer os om de afvejninger, vi foretager.
JetStream indeholder benchmarks fra SunSpider 1.0.2 og Octane 2 JavaScript benchmark suiter. Det inkluderer også benchmarks fra LLVM compiler open source-projektet, kompileret til JavaScript ved hjælp af Emscripten 1.13. Det inkluderer også et benchmark baseret på Apache Harmony open source-projektets HashMap, håndoversat til JavaScript. Flere oplysninger om de benchmarks, der er inkluderet i JetStream, er tilgængelige på JetStream in Depth-siden.
vi er glade for at introducere dette nye benchmark. For at køre det skal du blot besøge browserbench.org/JetStream. du kan arkivere fejl mod benchmarket ved hjælp af bug management system under værktøj/test komponent.
