idag introducerar vi en ny WebKit JavaScript benchmark test suite, JetStream. JetStream kodifierar vad vår de facto-process har varit-att kombinera latens-och genomströmningsriktmärken med ungefär lika viktning och fånga både mätvärden för traditionella JavaScript-programmeringsstilar samt nya JavaScript-baserade tekniker som har fångat våra fantasier. Poäng på JetStream är en bra indikator på prestanda användarna skulle se i avancerade webbapplikationer som spel.
optimering av prestanda för vår JavaScript-motor är en hög prioritet för WebKit-projektet. Exempel på några av de förbättringar vi introducerade under det senaste året inkluderar concurrent compilation, generational GC och FTL JIT. Att konstruera sådana förbättringar kräver fokus: vi försöker prioritera projekt med hög effekt framför att bygga och underhålla komplexa optimeringar som har mindre fördelar. Således motiverar vi prestationsarbete med riktmärken som illustrerar vilka typer av arbetsbelastningar som WebKit-användare sannolikt kommer att stöta på. Denna filosofi om benchmark-driven utveckling har länge varit en del av WebKit.
det tidigare tillståndet för JavaScript-Benchmarking
när vi gjorde förbättringar av WebKit JavaScript-motorn fann vi att ingen enda benchmark-svit var helt representativ för de scenarier som vi ville förbättra. Vi gillar att JSBench mäter prestanda för JavaScript-kod på populära webbplatser, men WebKit gör redan mycket bra på detta riktmärke. Vi gillar SunSpider för dess täckning av vanligt använda språkkonstruktioner och för det faktum att dess körtid är representativ för kodens körtid på webben, men det blir kort för att mäta toppgenomströmning. Vi gillar oktan, men det snedställs för långt i andra riktningen: det är användbart för att bestämma vår Motors maximala genomströmning men är inte tillräckligt känslig för den prestanda du sannolikt skulle se på typiska webbarbetsbelastningar. Det bagatelliserar också nya JavaScript-tekniker som asm.js; endast en av Octanes 15 riktmärken var en asm.js-test, och detta test ignorerar flytpunktsprestanda.
hitta bra asm.JS benchmarks är svårt. Även om Emscripten vinner mindshare, dess tester är långvariga och tills nyligen saknade en webbsele. Så vi byggde vår egen asm.JS benchmarks genom att använda tester från LLVM test suite. Dessa C-och C++ – tester används av LLVM-utvecklare för att spåra prestandaförbättringar av clang/LLVM-kompilatorstacken. Emscripten själv använder LLVM för att generera JavaScript-kod. Detta gör LLVM – testpaketet särskilt lämpligt för att testa hur bra en JavaScript-motor hanterar inbyggd kod. En annan fördel med våra nya tester är att de är mycket snabbare att köra än Emscripten test suite.
med bra JavaScript-riktmärken kan vi med säkerhet driva ambitiösa förbättringar av WebKit. Till exempel styrde SunSpider vårt samtidiga kompileringsarbete, medan asm.js-tester och Octanes genomströmningstester motiverade vårt arbete med FTL JIT. Men att låta våra tester baseras på en hodgepodge av dessa olika riktmärkesviter har blivit opraktiskt. Det är svårt att berätta för bidragsgivare vad de ska testa om det inte finns någon enhetlig testsvit som kan berätta för dem om deras förändring hade önskad effekt på prestanda. Vi vill ha en testsvit som kan rapportera en poäng i slutet, och vi vill att den här poängen ska vara representativ för Webkits framtida riktning.
designa den nya JetStream Benchmark Suite
olika WebKit-komponenter kräver olika metoder för att mäta prestanda. Till exempel, för DOM performance, introducerade vi bara hastighetsmätarens riktmärke. I vissa fall fungerar det uppenbara tillvägagångssättet ganska bra: till exempel kan många layoutoptimeringar och renderingsoptimeringar drivas genom att mäta sidladdningstid på representativa webbsidor. Men att mäta prestanda för ett programmeringsspråkimplementering kräver mer subtilitet. Vi vill öka riktmärkenas känslighet för kärnmotorförbättringar, men inte så mycket att vi förlorar perspektiv på hur dessa motorförbättringar spelar ut på riktiga webbplatser. Vi vill minimera möjligheterna för systembrus att kasta bort våra mätningar, men när som helst en arbetsbelastning är inneboende utsatt för buller, vill vi ha ett riktmärke för att visa detta. Vi vill att våra riktmärken ska representera en HiFi-approximation av de arbetsbelastningar som WebKit-användare sannolikt kommer att bry sig om.
JetStream kombinerar en mängd olika JavaScript-riktmärken, som täcker en mängd avancerade arbetsbelastningar och programmeringstekniker, och rapporterar en enda poäng som balanserar dem med ett geometriskt medelvärde. Varje test körs tre gånger och poäng rapporteras med 95% konfidensintervall. Varje riktmärke mäter en tydlig arbetsbelastning, och ingen enda optimeringsteknik är tillräcklig för att påskynda alla riktmärken. Vissa riktmärken visar kompromisser, och aggressiv eller specialiserad optimering för ett riktmärke kan göra ett annat riktmärke långsammare. Att demonstrera avvägningar är avgörande för vårt arbete. Som diskuterats i mitt tidigare inlägg om vår nya JIT-kompilator försöker WebKit dynamiskt anpassa sig till arbetsbelastningen med olika exekveringsnivåer. Men det här är aldrig perfekt. Till exempel, medan vår nya FTL JIT-kompilator ger oss fantastiska hastigheter på toppgenomströmningstester, orsakar det små regressioner i vissa ramp-up-tester. Nya optimeringar för avancerade språkkörningstider stöter ofta på sådana avvägningar, och vårt mål med JetStream är att ha ett riktmärke som informerar oss om de avvägningar vi gör.
JetStream innehåller riktmärken från SunSpider 1.0.2 och Octane 2 JavaScript benchmark suites. Den innehåller också riktmärken från LLVM-kompilatorn open source-projektet, sammanställt till JavaScript med Emscripten 1.13. Det innehåller också ett riktmärke baserat på Apache Harmony open source-projektets HashMap, handöversatt till JavaScript. Mer information om riktmärkena som ingår i JetStream finns på JetStream in Depth-sidan.
vi är glada att introducera detta nya riktmärke. För att köra det, besök bara browserbench.org/JetStream. du kan arkivera buggar mot riktmärket med Webkits bugghanteringssystem under komponenten verktyg/Test.
