メインコンテンツまでスキップ

Octaneの廃止

· 約8分
V8チーム

JavaScriptベンチマークの歴史は、絶え間ない進化の物語です。ウェブが単純な文書から動的なクライアントサイドアプリケーションへと拡張するにつれて、新しいJavaScriptベンチマークが作成され、新しいユースケースで重要なワークロードを測定するようになりました。この絶え間ない変化により、個々のベンチマークは有限の寿命を持つようになりました。ウェブブラウザや仮想マシン（VM）の実装が特定のテストケースに過度に最適化し始めると、ベンチマーク自体が元のユースケースの有効な代替物でなくなります。最初期のJavaScriptベンチマークの一つであるSunSpiderは、初期の迅速な最適化コンパイラの提供にインセンティブを与えました。しかし、VMエンジニアがマイクロベンチマークの限界を発見し、最適化する新しい方法を見つけた結果、ブラウザコミュニティは推奨ベンチマークとしてSunSpiderの廃止を決定しました。

Octaneの始まり​

初期のマイクロベンチマークの弱点を緩和するよう設計されたOctaneベンチマークスイートは2012年に初めてリリースされました。それは以前の簡単なV8テストケースセットから発展し、一般的なウェブパフォーマンスのベンチマークとして一般的になりました。Octaneは異なるワークロードをカバーするように設計された17のテストで構成されており、Martin RichardsのカーネルシミュレーションテストからMicrosoftのTypeScriptコンパイラが自分自身をコンパイルするバージョンまで幅広い内容を含んでいます。Octaneの内容は、その作成時のJavaScriptパフォーマンス測定に関する一般的な知恵を反映しています。

効果の減少と過剰最適化​

リリース後の最初の数年間で、OctaneはJavaScript VMエコシステムにユニークな価値を提供しました。それはV8を含むエンジンがピークパフォーマンスを求めるアプリケーションクラスに対して性能を最適化することを可能にしました。これらのCPU集約型のワークロードは、当初はVM実装によって十分にサービスが提供されていませんでした。Octaneはエンジン開発者が計算負荷の高いアプリケーションをJavaScriptでC++やJavaに代わる選択肢として実行できる速度に到達させる最適化を提供するのを助けました。また、Octaneはゴミ収集の改善を促進し、ウェブブラウザが長時間または予測不可能な停止を回避するのに役立ちました。

しかし2015年までに、ほとんどのJavaScript実装はOctaneで高スコアを達成するために必要なコンパイラ最適化を実装しました。Octaneでさらに高いベンチマークスコアを目指すことは、実際のウェブページのパフォーマンスの改良においてますます限界的な改善をもたらしました。Octaneと一般的なウェブサイトの読み込みの実行プロファイルの調査により、ベンチマークがV8のパーサーやブラウザの読み込みスタックを実際のコードのようには行使していないことが明らかになりました。さらに、OctaneのJavaScriptのスタイルは、ほとんどの現代的なフレームワークやライブラリで使用される慣用句やパターン（トランスパイルされたコードや新しいES2015+言語機能を含む）と一致していません。これにより、OctaneでV8の性能を測定することは、現代のウェブにおける重要なユースケースを捕らえることができないことを意味しました。それは、フレームワークを迅速に読み込むこと、大規模なアプリケーションを新しい状態管理パターンでサポートすること、またはES2015+の機能がES5の同等機能と同じくらい高速であることを保証することなどです。

さらに、JavaScriptの最適化がOctaneスコアを向上させる一方で、現実世界のシナリオに悪影響を及ぼすことがある点に気付き始めました。Octaneは、関数呼び出しのオーバーヘッドを最小限に抑えるために積極的なインライニングを促進しますが、Octaneに特化したインライニング戦略は、コンパイルコストの増加やメモリ使用量の増加によって現実世界の使用ケースで退化を引き起こすことがあります。本当に実際の使用に役立つ最適化である場合でも（例えば動的プリテンヤリングのように）、Octaneスコアを追求することは効果がほとんどない、あるいは一般的なケースで性能を低下させる可能性のある過度に特定的なヒューリスティックを作り上げる結果になります。我々は、Octane由来のプリテンヤリングのヒューリスティックがEmberなどの最新フレームワークで性能低下をもたらしたことを発見しました。instanceof演算子は、Octane特有の狭いケースに合わせられた最適化の別の例であり、Node.jsアプリケーションで大きな退化を引き起こしました。

もう一つの問題は、時間の経過に伴い、Octaneの小さなバグ自身が最適化の対象になってしまう点です。たとえば、Box2DWebベンチマークでは、2つのオブジェクトが<と>=演算子で比較されるというバグを利用することで、Octane上で約15%の性能向上が得られました。しかし残念なことに、この最適化は実際の使用では何の効果もなく、より一般的な比較最適化を複雑にしました。Octaneは、時には現実世界の最適化に対してさえ否定的な影響を与えることがあります。他のVMに取り組む技術者たちは指摘していますが、Octaneはしばしば怠惰な解析（現実のウェブサイトが頻繁に含む死んだコードの量を考慮すれば、多くの実ウェブサイトのロードを高速化する技術）をペナルティ化しているようです。

Octaneと他の合成ベンチマークを超えて​

これらの例は、Octaneスコアを増加させるために最適化された結果、実際のウェブサイトの実行に悪影響を与えた問題の一部にすぎません。同様の問題は、KrakenやJetStreamなどの他の静的または合成ベンチマークにも存在します。要するに、このようなベンチマークは現実世界の速度を測定するのには不十分であり、VM技術者が狭い使用ケースを過剰に最適化し、一般的なケースを十分に最適化しないインセンティブを生み出し、結果的にJavaScriptコードの速度を低下させる原因となっています。

ほとんどのJS VMでスコアが頭打ちになり、特定のOctaneベンチマークを最適化することと、より広範囲の現実世界のコードの速度向上を実現することとの間で増加する対立を考慮すると、Octaneを推奨ベンチマークとして廃止する時期が来たと考えています。

Octaneは、計算コストの高いJavaScriptにおいてJSエコシステムが大きく進歩することを可能にしました。しかし、次のフロンティアは実際のウェブページ、最新のライブラリ、フレームワーク、ES2015+言語機能、新しい状態管理のパターン、イミュータブルオブジェクトの割り当て、およびモジュール バンドリング性能を向上させることです。V8はNode.jsのサーバー側を含む多くの環境で動作しているため、我々は実際のNodeアプリケーションを理解し、AcmeAirなどのワークロードを通じてサーバー側のJavaScript性能を測定することにも注力しています。

測定方法論の改善やより現実的なワークロードに関する投稿を、ここでぜひご覧ください。我々は、ユーザーや開発者に最も重要な性能を追求し続けることを楽しみにしています！