Aujourd’hui, nous présentons une nouvelle suite de tests de benchmark JavaScript WebKit, JetStream. JetStream codifie ce que notre processus de facto a été: combiner des benchmarks de latence et de débit avec une pondération à peu près égale, et capturer à la fois les métriques des styles de programmation JavaScript traditionnels ainsi que les nouvelles technologies basées sur JavaScript qui ont capturé notre imagination. Les scores sur JetStream sont un bon indicateur des performances que les utilisateurs verraient dans les applications Web avancées telles que les jeux.
L’optimisation des performances de notre moteur JavaScript est une priorité pour le projet WebKit. Parmi les améliorations que nous avons apportées au cours de la dernière année, citons la compilation simultanée, le GC générationnel et le JIT FTL. L’ingénierie de telles améliorations nécessite une attention particulière : nous essayons de donner la priorité à des projets à fort impact plutôt qu’à la construction et à la maintenance d’optimisations complexes qui présentent des avantages moindres. Ainsi, nous motivons le travail de performance avec des benchmarks qui illustrent les types de charges de travail que les utilisateurs de WebKit rencontreront probablement. Cette philosophie de développement axé sur les benchmark fait depuis longtemps partie de WebKit.
L’état précédent du Benchmarking JavaScript
Au fur et à mesure que nous avons apporté des améliorations au moteur JavaScript WebKit, nous avons constaté qu’aucune suite de benchmark unique n’était entièrement représentative des scénarios que nous voulions améliorer. Nous aimons que JSBench mesure les performances du code JavaScript sur les sites Web populaires, mais WebKit fait déjà très bien sur ce benchmark. Nous aimons SunSpider pour sa couverture des constructions de langage couramment utilisées et pour le fait que son temps d’exécution est représentatif du temps d’exécution du code sur le Web, mais il est insuffisant pour mesurer le débit de pointe. Nous aimons l’Octane, mais il biaise trop dans l’autre sens: il est utile pour déterminer le débit maximal de notre moteur, mais n’est pas assez sensible aux performances que vous auriez le plus de chances de voir sur des charges de travail Web typiques. Il minimise également les nouvelles technologies JavaScript comme asm.js ; un seul des 15 benchmarks d’Octane était un asm.test js, et ce test ignore les performances en virgule flottante.
Trouver un bon asm.js benchmarks est difficile. Même si Emscripten gagne mindshare, ses tests sont de longue durée et jusqu’à récemment, il manquait un harnais Web. Nous avons donc construit notre propre asm.benchmarks js en utilisant des tests de la suite de tests LLVM. Ces tests C et C++ sont utilisés par les développeurs LLVM pour suivre les améliorations des performances de la pile de compilateurs clang/LLVM. Emscripten lui-même utilise LLVM pour générer du code JavaScript. Cela rend la suite de tests LLVM particulièrement appropriée pour tester la façon dont un moteur JavaScript gère le code natif. Un autre avantage de nos nouveaux tests est qu’ils sont beaucoup plus rapides à exécuter que la suite de tests Emscripten.
Avoir de bons benchmarks JavaScript nous permet de poursuivre en toute confiance des améliorations ambitieuses de WebKit. Par exemple, SunSpider a guidé notre travail de compilation simultané, tandis que l’asm.les tests js et les tests de débit d’Octane ont motivé notre travail sur le JIT FTL. Mais permettre à nos tests d’être basés sur un méli-mélo de ces différentes suites de benchmark est devenu peu pratique. Il est difficile de dire aux contributeurs ce qu’ils devraient tester s’il n’y a pas de suite de tests unifiée qui puisse leur dire si leur changement a eu l’effet souhaité sur les performances. Nous voulons une suite de tests qui puisse rapporter un score à la fin, et nous voulons que ce score soit représentatif de l’orientation future de WebKit.
Conception de la nouvelle suite JetStream Benchmark
Différents composants WebKit nécessitent des approches différentes pour mesurer les performances. Par exemple, pour les performances DOM, nous venons d’introduire le benchmark du compteur de vitesse. Dans certains cas, l’approche évidente fonctionne plutôt bien: par exemple, de nombreuses optimisations de mise en page et de rendu peuvent être pilotées en mesurant le temps de chargement des pages sur des pages Web représentatives. Mais mesurer les performances d’une implémentation de langage de programmation nécessite plus de subtilité. Nous voulons augmenter la sensibilité des benchmarks aux améliorations du moteur de base, mais pas tellement que nous perdons la perspective de la façon dont ces améliorations du moteur se déroulent dans de vrais sites Web. Nous voulons minimiser les possibilités pour le bruit du système de rejeter nos mesures, mais chaque fois qu’une charge de travail est intrinsèquement sujette au bruit, nous voulons un point de référence pour le montrer. Nous voulons que nos benchmarks représentent une approximation haute fidélité des charges de travail susceptibles d’intéresser les utilisateurs de WebKit.
JetStream combine une variété de benchmarks JavaScript, couvrant une variété de charges de travail avancées et de techniques de programmation, et rapporte un score unique qui les équilibre à l’aide d’une moyenne géométrique. Chaque test est exécuté trois fois et les scores sont rapportés avec des intervalles de confiance de 95%. Chaque benchmark mesure une charge de travail distincte, et aucune technique d’optimisation unique n’est suffisante pour accélérer tous les benchmarks. Certains benchmarks démontrent des compromis, et une optimisation agressive ou spécialisée pour un benchmarks peut ralentir un autre benchmarks. La démonstration des compromis est cruciale pour notre travail. Comme discuté dans mon article précédent sur notre nouveau compilateur JIT, WebKit essaie de s’adapter dynamiquement à la charge de travail en utilisant différents niveaux d’exécution. Mais ce n’est jamais parfait. Par exemple, alors que notre nouveau compilateur JIT FTL nous donne des accélérations fantastiques sur les tests de débit de pointe, il provoque de légères régressions dans certains tests de montée en puissance. Les nouvelles optimisations pour les runtimes de langage avancés se heurtent souvent à de tels compromis, et notre objectif avec JetStream est d’avoir un benchmark qui nous renseigne sur les compromis que nous faisons.
JetStream inclut des benchmarks des suites de benchmarks JavaScript SunSpider 1.0.2 et Octane 2. Il inclut également des benchmarks du projet open source du compilateur LLVM, compilés en JavaScript à l’aide d’Emscripten 1.13. Il comprend également un benchmark basé sur le HashMap du projet open source Apache Harmony, traduit à la main en JavaScript. Plus d’informations sur les benchmarks inclus dans JetStream sont disponibles sur la page JetStream en profondeur.
Nous sommes ravis de présenter cette nouvelle référence. Pour l’exécuter, il suffit de visiter browserbench.org/JetStream . Vous pouvez classer les bogues par rapport au benchmark en utilisant le système de gestion des bogues de WebKit sous le composant Outils/Tests.
