I Dag introduserer Vi En ny WebKit JavaScript benchmark test suite, JetStream. JetStream kodifiserer hva vår de facto prosess har vært-å kombinere latens og gjennomstrømmings benchmarks med omtrent lik vekting, og fange både beregninger av tradisjonelle JavaScript-programmerings stiler samt nye JavaScript-baserte teknologier som har fanget vår fantasi. Poeng På JetStream er en god indikator på ytelsen brukerne vil se i avanserte webapplikasjoner som spill.
Optimalisering av ytelsen til Vår JavaScript-motor er en høy prioritet For WebKit-prosjektet. Eksempler på noen av forbedringene vi introduserte i det siste året inkluderer concurrent compilation, generational GC, OG FTL JIT. Å utvikle slike forbedringer krever fokus: vi prøver å prioritere prosjekter med høy effekt fremfor å bygge og opprettholde komplekse optimaliseringer som har mindre fordeler. Dermed motiverer vi ytelsesarbeid med referanser som illustrerer hvilke typer arbeidsbelastninger Som WebKit-brukere sannsynligvis vil støte på. Denne filosofien om benchmark-drevet utvikling har lenge vært En Del Av WebKit.
Den Forrige Tilstanden For JavaScript-Benchmarking
Da Vi gjorde forbedringer Til WebKit JavaScript-motoren, fant vi ut at ingen enkelt benchmark suite var helt representativ for scenariene som vi ønsket å forbedre. Vi liker At JSBench måler Ytelsen Til JavaScript-kode på populære nettsteder, Men WebKit gjør det allerede veldig bra på dette referansen. Vi liker SunSpider for sin dekning av vanlig brukte språkkonstruksjoner og for det faktum at kjøretiden er representativ for kjøretiden til kode på nettet, men det faller kort for å måle topp gjennomstrømning. Vi liker Octane, men det skråner for langt i den andre retningen: det er nyttig for å bestemme motorens topp gjennomstrømning, men er ikke følsom nok til ytelsen du mest sannsynlig vil se på typiske webarbeidsbelastninger. Det nedtoner også nye JavaScript-teknologier som asm.js; bare En Av Octanes 15 referanser var en asm.js test, og denne testen ignorerer flyttall ytelse.
Finne god asm.js benchmarks er vanskelig. Selv Om Emscripten er å få mindshare, sine tester er langvarige og inntil nylig, manglet en web sele. Så vi bygget vår egen asm.js benchmarks ved hjelp av tester FRA LLVM test suite. Disse c-og c++ – testene brukes AV LLVM-utviklere for å spore ytelsesforbedringer av clang / LLVM-kompilatorstakken. Emscripten selv bruker LLVM å generere JavaScript-kode. DETTE gjør LLVM test suite spesielt egnet for å teste hvor godt En JavaScript-motor håndterer innfødt kode. En annen fordel med våre nye tester er at De er mye raskere å kjøre Enn Emscripten test suite.
å Ha gode JavaScript benchmarks tillater oss å trygt forfølge ambisiøse forbedringer Av WebKit. For eksempel, SunSpider guidet vår samtidige kompilering arbeid, mens asm.js-tester og Octans gjennomstrømningstester motiverte vårt arbeid på FTL JIT. Men å la vår testing være basert på en hodgepodge av disse forskjellige benchmark-suitene, har blitt upraktisk. Det er vanskelig å fortelle bidragsytere hva de skal teste hvis det ikke finnes en enhetlig testpakke som kan fortelle dem om endringen hadde den ønskede effekten på ytelsen. Vi vil ha en testpakke som kan rapportere en poengsum til slutt, og vi vil at denne poengsummen skal være representativ For Webkits fremtidige retning.
Utforming Av Den Nye JetStream Benchmark Suite
Ulike WebKit-komponenter krever ulike tilnærminger til måling av ytelse. FOR EKSEMPEL, FOR DOM ytelse, vi nettopp introdusert Speedometer benchmark. I noen tilfeller, den åpenbare tilnærmingen fungerer ganske bra: for eksempel kan mange oppsett og rendering optimaliseringer drives ved å måle siden lastetiden på representative nettsider. Men måling av ytelsen til et programmeringsspråk implementering krever mer subtilitet. Vi ønsker å øke benchmarks følsomhet for kjernemotorforbedringer, men ikke så mye at vi mister perspektiv på hvordan disse motorforbedringene spiller ut i ekte nettsteder. Vi ønsker å minimere mulighetene for systemstøy til å kaste av våre målinger, men når en arbeidsbelastning er iboende utsatt for støy, vil vi ha en målestokk for å vise dette. Vi vil at våre referanser skal representere en nøyaktig tilnærming av arbeidsbelastningene Som WebKit-brukere sannsynligvis vil bry seg om.
JetStream kombinerer En rekke JavaScript benchmarks, som dekker en rekke avanserte arbeidsbelastninger og programmeringsteknikker, og rapporterer en enkelt poengsum som balanserer dem ved hjelp av et geometrisk gjennomsnitt. Hver test kjøres tre ganger og score rapporteres med 95% konfidensintervall. Hver benchmark måler en distinkt arbeidsbelastning, og ingen enkelt optimaliseringsteknikk er tilstrekkelig til å øke hastigheten på alle benchmarks. Noen benchmarks demonstrere avveininger, og aggressiv eller spesialisert optimalisering for en benchmark kan gjøre en annen benchmark tregere. Å demonstrere avveininger er avgjørende for vårt arbeid. Som diskutert i mitt forrige innlegg om vår nye jit-kompilator, Prøver WebKit å tilpasse seg dynamisk til arbeidsbelastning ved hjelp av forskjellige utførelsesnivåer. Men dette er aldri perfekt. For eksempel, mens vår nye FTL JIT kompilator gir oss fantastiske speed-ups på topp gjennomstrømmingstester, forårsaker det små regresjoner i noen ramp-up tester. Nye optimaliseringer for avanserte språk runtimes ofte kjøre inn i slike avveininger, og vårt mål Med JetStream er å ha en benchmark som informerer oss om avveininger som vi gjør.
JetStream inkluderer benchmarks Fra SunSpider 1.0.2 Og Octane 2 JavaScript benchmark suiter. Det inkluderer også benchmarks FRA LLVM compiler open source project, kompilert Til JavaScript Ved Hjelp Av Emscripten 1.13. Det inkluderer også en benchmark basert På Apache Harmony open source prosjektets HashMap, hånd-oversatt Til JavaScript. Mer informasjon om benchmarks inkludert I JetStream er tilgjengelig På JetStream I Dybden side.
Vi er glade for å introdusere denne nye referansen. For å kjøre det, bare besøk browserbench.org/JetStream. Du kan sende inn feil mot referansen ved Hjelp Av Webkits feilstyringssystem under Verktøy / Tests-komponenten.
