「JavaScript」タグの記事が10件件あります

JavaScriptを高速で動作させることは、応答性の高いWebアプリケーションには欠かせません。V8の高度な最適化をもってしても、起動時に重要なJavaScriptを解析およびコンパイルすることがパフォーマンスにボトルネックをもたらす場合があります。初期スクリプトのコンパイル中にどのJavaScript関数をコンパイルするかを把握することで、Webページの読み込みを高速化できます。

V8の最上位最適化コンパイラTurbofanは、Sea of Nodes (SoN)を使用する数少ない大規模プロダクションコンパイラの1つとして知られています。しかし、約3年前からSea of Nodesを廃止し、より伝統的な制御フローグラフ (CFG) 中間表現 (IR)に戻りました。それをTurboshaftと名付けました。現在では、TurbofanのJavaScriptバックエンド全体がTurboshaftを使用しており、WebAssemblyはその全パイプラインを通じてTurboshaftを使用しています。Turbofanの2つの部分ではまだSea of Nodesが一部使用されています。1つは組み込みパイプラインで、これをTurboshaftに置き換えつつあります。もう1つはJavaScriptパイプラインのフロントエンドで、これをMaglevという別のCFGベースのIRに置き換えています。このブログ記事では、Sea of Nodesを廃止することになった理由を説明します。

V8では、JavaScriptのパフォーマンス向上に常に努めています。この努力の一環として、最近JetStream2のベンチマークスイートを見直し、パフォーマンスの問題を解消しました。この投稿では、async-fsベンチマークで大幅な2.5倍の改善を達成し、全体スコアに著しい向上をもたらした特定の最適化について詳しく説明します。この最適化はベンチマークから着想を得ましたが、実際のコードでも類似のパターンが見られます。

あなたはundefined、true、その他のコアJavaScriptオブジェクトがどこから来るのか考えたことがありますか？これらのオブジェクトは、任意のユーザー定義オブジェクトの基本単位であり、最初に存在している必要があります。V8はこれらを固定不変なルートと呼び、それらは専用のヒープ – 読み取り専用ヒープに住んでいます。これらは頻繁に使用されるため、迅速なアクセスが重要です。そしてコンパイル時にメモリアドレスを正しく予測するほど迅速な方法はないでしょうか？

速さが単なる特徴ではなく、生活の一部である刺激的なV8の世界へようこそ。2023年を締めくくるにあたり、今年達成したV8の印象的な成果を祝う時が来ました。

革新的なパフォーマンス最適化を通じて、V8はWebの進化し続ける景観において可能な限界を押し広げ続けています。今年は、新しい中間層コンパイラを導入し、上位層コンパイラのインフラストラクチャ、ランタイム、ガベージコレクタにいくつかの改善を実施しました。その結果、広範囲で大幅な速度向上が実現しました。

Chrome M117では、新しい最適化コンパイラMaglevを導入しました。Maglevは既存のSparkplugとTurboFanコンパイラの間に位置し、高速な最適化コンパイラとしての役割を果たし、十分に良いコードを十分に速く生成します。

2021年まで、V8には2つの主要な実行階層がありました。Ignition（インタープリタ）と、ピーク性能を重視したV8の最適化コンパイラTurboFanです。すべてのJavaScriptコードは最初にIgnitionのバイトコードにコンパイルされ、それをインタープリトして実行されます。実行中、V8はプログラムの挙動を追跡し、オブジェクトの形状や型を記録します。ランタイムの実行メタデータとバイトコードの両方が最適化コンパイラに供給され、高性能でしばしば推測的な機械コードが生成され、インタープリタよりもはるかに速く実行されます。

V8 v9.1では、一時的に組み込み機能をデスクトップで非組み込み化しました。組み込み機能の活用はメモリ使用量を大幅に改善しますが、組み込み機能とJITコンパイルされたコード間での関数呼び出しが重大なパフォーマンスペナルティを伴う場合があります。このコストはCPUのマイクロアーキテクチャに依存します。この記事では、この現象がなぜ発生するのか、パフォーマンスの状況、そして長期的にこれを解決するための計画について説明します。

superキーワードは、オブジェクトの親に存在するプロパティや関数にアクセスするために使用できます。

以前は、superプロパティ（例えばsuper.x）へのアクセスはランタイム呼び出しを介して実装されていました。V8 v9.0以降、非最適化コードでインラインキャッシュ (IC)システムを再利用し、ランタイムへのジャンプなしで適切な最適化コードを生成するようになりました。

はじめに​

ChromeとEmscriptenによる最近の作業により、WebAssemblyアプリケーションで最大4GBのメモリを使用できるようになりました。以前の制限は2GBでした。そもそも制限があるのは奇妙に思えるかもしれませんが（結局512MBや1GBのメモリ使用を許可するために特別な作業は必要ありませんでした）、実際には2GBから4GBにジャンプする際にはブラウザでもツールチェーンでも特別なことが発生します。この投稿ではそれについて説明します。