Ruhestand von Octane

Die Geschichte der JavaScript-Benchmarks ist eine Geschichte ständiger Weiterentwicklung. Während sich das Web von einfachen Dokumenten zu dynamischen Client-seitigen Anwendungen entwickelte, wurden neue JavaScript-Benchmarks entwickelt, um Arbeitslasten zu messen, die für neue Anwendungsfälle wichtig wurden. Dieser ständige Wandel hat dazu geführt, dass einzelne Benchmarks eine begrenzte Lebensdauer haben. Wenn Webbrowser- und virtuelle Maschinen-Implementierungen (VM) beginnen, spezifische Testfälle übermäßig zu optimieren, hören Benchmarks auf, effektive Stellvertreter für ihre ursprünglichen Anwendungsfälle zu sein. Einer der ersten JavaScript-Benchmarks, SunSpider, bot frühzeitig Anreize zur Bereitstellung schneller optimierender Compiler. Allerdings stießen VM-Ingenieure auf die Einschränkungen von Mikro-Benchmarks und fanden neue Wege zur Optimierung um die SunSpider Einschränkungen herum, was dazu führte, dass die Browsergemeinschaft SunSpider in den Ruhestand versetzte als empfohlenen Benchmark.

Die Entstehung von Octane

Um einige der Schwächen früher Mikro-Benchmarks zu mildern, wurde die Octane-Benchmark-Suite erstmals 2012 veröffentlicht. Sie entwickelte sich aus einer früheren Reihe einfacher V8-Testfälle und wurde zu einem gängigen Benchmark für die allgemeine Web-Performance. Octane besteht aus 17 verschiedenen Tests, die entwickelt wurden, um eine Vielzahl unterschiedlicher Arbeitslasten abzudecken, von Martin Richards’ Kern-Simulationstest bis hin zu einer Version des Microsoft TypeScript Compilers, der sich selbst kompiliert. Der Inhalt von Octane spiegelte die vorherrschende Meinung zur Messung der JavaScript-Performance zur Zeit seiner Entstehung wider.

Abnehmender Nutzen und Überoptimierung

In den ersten Jahren nach seiner Veröffentlichung bot Octane der JavaScript-VM-Ökosystem ein einzigartiger Wert. Es ermöglichte Engines, einschließlich V8, ihre Leistung für eine Klasse von Anwendungen zu optimieren, die Höchstleistung verlangten. Diese CPU-intensiven Arbeitslasten wurden ursprünglich von VM-Implementierungen unterversorgt. Octane half den Entwicklern von Engines bei der Implementierung von Optimierungen, die es ermöglichten, dass rechenintensive Anwendungen Geschwindigkeiten erreichten, die JavaScript zu einer praktikablen Alternative zu C++ oder Java machten. Darüber hinaus trieb Octane Verbesserungen bei der Garbage Collection voran, wodurch Webbrowser lange oder unvorhersehbare Pausen vermeiden konnten.

Bis 2015 hatten jedoch die meisten JavaScript-Implementierungen die Compiler-Optimierungen implementiert, die erforderlich waren, um hohe Punktzahlen bei Octane zu erreichen. Das Streben nach noch höheren Benchmark-Werten bei Octane führte zu zunehmend marginalen Verbesserungen in der Leistung realer Webseiten. Untersuchungen zum Ausführungsprofil beim Ausführen von Octane im Vergleich zum Laden gängiger Websites (wie Facebook, Twitter oder Wikipedia) zeigten, dass der Benchmark weder den Parser von V8 noch den Browser-Lade-Stack so beansprucht wie echter Code. Darüber hinaus entspricht der Stil von Octanes JavaScript nicht den Idiomen und Mustern, die von den meisten modernen Frameworks und Bibliotheken verwendet werden (ganz zu schweigen von transpiliertem Code oder neuen ES2015+ Sprachfeatures). Dies bedeutet, dass die Verwendung von Octane zur Messung der V8-Leistung wichtige Anwendungsfälle für das moderne Web nicht erfasste, wie z. B. das schnelle Laden von Frameworks, die Unterstützung großer Anwendungen mit neuen Mustern der Zustandsverwaltung oder die Sicherstellung, dass ES2015+ Features so schnell wie ihre ES5-Äquivalente sind.

Außerdem begannen wir zu bemerken, dass JavaScript-Optimierungen, die höhere Octane-Werte erzielten, oft nachteilige Auswirkungen auf reale Szenarien hatten. Octane fördert aggressives Inlining, um den Overhead von Funktionsaufrufen zu minimieren, aber Inlining-Strategien, die auf Octane abgestimmt sind, führten in realen Anwendungsfällen zu Rückschritten durch höhere Kompilierungskosten und höheren Speicherverbrauch. Selbst wenn eine Optimierung in der realen Welt tatsächlich nützlich sein könnte, wie es bei dynamic pretenuring der Fall ist, kann das Streben nach höheren Octane-Werten dazu führen, dass übermäßig spezifische Heuristiken entwickelt werden, die in allgemeineren Fällen wenig Wirkung zeigen oder sogar die Leistung verschlechtern. Wir stellten fest, dass Octane-abgeleitete Pretenuring-Heuristiken zu Leistungsverschlechterungen in modernen Frameworks wie Ember führten. Der instanceof-Operator war ein weiteres Beispiel für eine Optimierung, die für einen engen Satz Octane-spezifischer Fälle zugeschnitten war und zu erheblichen Rückschritten in Node.js-Anwendungen führte.

Ein weiteres Problem ist, dass kleine Fehler in Octane im Laufe der Zeit selbst zu Zielen für Optimierungen werden. Im Box2DWeb-Benchmark beispielsweise nutzte man einen Fehler aus, bei dem zwei Objekte mit den Operatoren < und >= verglichen wurden, was eine ~15%ige Leistungssteigerung in Octane zur Folge hatte. Leider hatte diese Optimierung keine Wirkung in der realen Welt und erschwerte allgemeinere Vergleichsoptimierungen. Octane bestraft manchmal sogar echte Optimierungen für die reale Welt: Ingenieure, die an anderen VMs arbeiten, haben bemerkt, dass Octane anscheinend Lazy Parsing bestraft, eine Technik, die hilft, dass die meisten echten Websites schneller laden, angesichts der Menge an totem Code, der häufig in freier Wildbahn gefunden wird.

Über Octane und andere synthetische Benchmarks hinaus

Diese Beispiele sind nur einige der vielen Optimierungen, die Octane-Werte erhöht haben, jedoch zum Nachteil des Betriebs echter Websites. Leider gibt es ähnliche Probleme bei anderen statischen oder synthetischen Benchmarks, einschließlich Kraken und JetStream. Kurz gesagt, solche Benchmarks sind unzureichende Methoden zur Messung der realen Geschwindigkeit und schaffen Anreize für VM-Ingenieure, eng gefasste Anwendungsfälle zu überoptimieren und allgemeine Fälle zu unteroptimieren, wodurch JavaScript-Code in freier Wildbahn langsamer wird.

Angesichts des Plateaus bei den Scores der meisten JS-VMs und des zunehmenden Konflikts zwischen der Optimierung für spezifische Octane-Benchmarks und der Implementierung von Geschwindigkeitssteigerungen für ein breiteres Spektrum an realem Code glauben wir, dass es an der Zeit ist, Octane als empfohlenen Benchmark in den Ruhestand zu versetzen.

Octane ermöglichte es dem JS-Ökosystem, große Fortschritte bei rechenintensivem JavaScript zu erzielen. Die nächste Herausforderung besteht jedoch darin, die Leistung von echten Webseiten, modernen Bibliotheken, Frameworks, ES2015+ Sprachfeatures, neuen Mustern des State Managements, immutable Object Allocation und Modul Bündelung zu verbessern. Da V8 in vielen Umgebungen läuft, einschließlich serverseitig in Node.js, investieren wir auch Zeit, um reale Node-Anwendungen zu verstehen und die serverseitige JavaScript-Leistung durch Workloads wie AcmeAir zu messen.

Schauen Sie hier vorbei, um weitere Beiträge über Verbesserungen in unserer Messemethodik und neue Workloads zu lesen, die die Leistung in der realen Welt besser repräsentieren. Wir freuen uns darauf, weiterhin die Leistung zu verfolgen, die für Nutzer und Entwickler am wichtigsten ist!