テテのつぶやき [ページ: 1 2 3 4 5 6 7 ... ]

Firefox 145.0.2独自ビルドTEST2などで独自のLLVMパス(TeInliner)を適用した結果、パフォーマンス(Speedometer 3.1のスコアの中央値)を維持させつつ、xul.dllのファイルサイズを約1.4MiB削減できましたようです (たぶん)。

ターゲット:

Firefox 145.0.2独自ビルド (Windows x64)

ツールチェーン:

LLVM 21.1.6とRust 1.91.1のカスタムビルド

主な最適化設定:

-clang:-O2、ThinLTO、CSIR PGO (Context-Sensitive IR PGO)有効

ターゲット:

• TEST0 (ベースライン): 独自パスTeInliner非適用
• TEST1: 独自パスTeInliner適用
• TEST2: TEST1の改良版

clang-clとlld-linkに独自のパスプラグイン(TeInlinerなど)を使わせたかったので、LLVM 21.1.6を改造してLLVM 22(開発中)のソースコードの一部を取り込みました。

なお、LLVM 21.1.6 (clang-cl)でWindows x64ターゲットのFirefoxをビルドすると、libopusというライブラリ内で不正なコードが生成され、動画再生時にRDDプロセスがクラッシュする不具合が確認されました。可変長引数を持つ関数がインライン展開される際に、不正なコードが生成される場合があるようです。恐らくLLVM 21.1.6のバグではないかと思います。他の場所でも同様の不具合が発生する可能性は捨てきれないので、可変長引数を持つ関数にnoinline属性を付けるパス(TeBugFix)も適用しました。

TeInlinerパスは、呼び出し元が1箇所だけの関数を検索し、特定の条件を満たした場合にその関数をインライン展開します。そうすることで、TeInlinerパスが実行された後の処理によって呼び出し先の関数が削除され、バイナリサイズが削減されることを狙いました。インターネット上で見つけた、メタ社の人たちが書いた資料を参考にしましたが、ソースコードは公開されていないようなので高度な処理は実装できませんでした。

各種FirefoxビルドのSpeedometer 3.1のスコアとxul.dllのファイルサイズを比較しました。グラフの黒くて太い横棒は中央値で、緑の三角形は平均値。外れ値が多かったので、平均値よりも中央値の方が正確な比較ができるかもしれません。またPGOを適用するたびに、xul.dllのファイルサイズは数百KiB程度変動することがあります。ベンチマークに使用したPCは、Windows 11 Pro 25H2、Ryzen 5 5600、GeForce GTX 750 Ti。

関数の並び替え方法を変えたFirefox 144.0独自ビルドを複数作り、幾つかのベンチマークテストを実行して比較しました。私のブラウザの使い方にあったワークロード(一般的なニュースサイトとかの閲覧)を考慮した結果、独自ビルド144.0 TEST2を採用してみることにしました。すなわち、現行のFirefoxが採用している方法(Temporal PGOとorderfileによる並び替え)ではなく、現行のChromiumが採用している方法(PGOとコールグラフによる並び替え)です。独自ビルド144.0とTEST2のどちらを採用するか迷っています。もう少し考えてみます。追記 (16:40頃): TEST2の方法を採用してみることにしました。独自ビルド144.0.2に適用します。

以下に各種ベンチマークテストの結果を載せます。今のところ理由は不明ですが、いつの間にか公式FirefoxのSpeedometer 3.1のスコアが伸びていて、私の独自ビルドを少し上回っていました。MotionMark等のベンチマークでは、私のビルドの方がスコアが良かったですが。

グラフの黒くて太い横棒は中央値で、緑の三角形は平均値。ベンチマークに使用したPCは、Windows 11 Pro 25H2、Ryzen 5 5600、GeForce GTX 750 Ti。

私の場合、MotionMarkで重視したい項目はHTMLやCSS関連なので、Multiply、Leaves、Designあたりでしょうか。SVGやCanvas関連の項目は優先度が下がります。MotionMark 1.3.1の各テスト項目についての説明などは、About MotionMark 1.3.1に載っています。MotionMarkはスコアのブレが大きめなので、サンプル数を増やしたいところですが、実行に時間がかかるのが難点。

プロセスを起動する時間の短さに関しては、Temporal PGOの効果が明確に出ているようです。スクリプトのループで繰り返し起動しているので、コールドスタートではないと思います。

MinGWのビルドエラーを解消するBug 1961213で行われた変更により、Windows版のFirefox 139以降において、関数の並び替えの方法が思いがけず変わってしまったように思うのですが、これはいわゆるリグレッションではないでしょうか?

具体的には、コールグラフを使用したデフォルトの並び替え方法(-call-graph-profile-sort)から、Temporal PGO (-mllvm -pgo-temporal-instrumentation)とorderfile.txtを使用した旧来の並び替え方法に戻ってしまったように思うのですが。私がなにか間違っているんでしょうか。

pgo_cg_sort関数のコメントには、「--call-graph-profile-sort is the default behavior for lld, and it proves to be more efficient than pgo-based orderfile.」と書かれており、Temporal PGOとorderfile.txtによる関数並び替えよりも、コールグラフによるデフォルトの並び替えの方が効率的だと書かれています。しかし実際には、clang-clとlld-linkを使うWindowsターゲットの場合にpgo_cg_sortはFalseを返すため、pgo_cg_sortのコメントと振る舞いが矛盾しているように見えます。

独自ビルドに先日追加したconvolve_horizontally_avx2という関数について。私が普段やっている方法で集めたプロファイルデータを使ってPGO (Profile-Guided Optimization)をこの関数に適用すると、出力画像の画素数が中程度の場合に、処理速度が大幅に悪化することが分かりました。PGOを適用しなければ高速なのですが。

原因を調べたところ、PGOによって関数内の基本ブロック(分岐命令やジャンプ命令等で区切られたコードの領域)が並び替えられたことが一因ではないかという気がしました。理由は分かりませんが、AVX2命令を使った最も重視してほしいループのブロックが関数の後ろの方へ追いやられ、ループを抜けた後の余りの処理を行うブロックが関数の先頭付近に配置されてしまうようでした。その重要なループのブロックは、他のブロックよりも実行回数が多いくらいなのですが。おかしいだろ！(つっこみ)。命令の数が他のブロックに比べて少なめだったから軽視されたんでしょうか。よくわからない……。

convolve_horizontally_avx2関数をPGOから除外することも検討しましたが、関数内のアルゴリズムを変えてみたところ、PGOを適用しても問題が起きなくなったため、今回の独自ビルドに反映させました。

PGO適用後に遅くなったコードでは、AVX2命令を多用したループを抜けた後の剰余処理を、SSSE3系の命令や既存のMozillaの関数などで行っていました。今回のビルドでは、剰余処理もできるだけAVX2命令で行うようにしました (CPUがIntelまたはAMD Zen以降に限ります)。余りの数をインデックスにし、VPMASKMOVD用のマスクデータが入っているテーブルを参照するアイディアはAIが教えてくれました。頭いいですね、天才ですね、と褒めておきました。AIもなんか嬉しそうでした。

ただ困ったことにAMDのCPUの中には、VPMASKMOVD等をIntelのマニュアル通りに実装していないものがある恐れが。Intelのマニュアルには、VPMASKMOVDはマスクビットが0の位置に該当するメモリ位置を参照してもフォルトは発生させないと明記されています。ところがAMDのマニュアルには、そのようにして参照した場合にフォルトが発生するかどうかは実装依存だと書かれているのです。

おぃ。これってエラッタに相当するような、ひどい欠陥だと思うのですが。Intelの仕様書通りに作ったプログラムが、AMDのCPU上でクラッシュするとかシャレになりません。せめてどの世代のCPUがその問題を抱えているのか、マニュアルに書いてほしいです。

VPMASKMOVDの振る舞いについて更に調べたところ、Zen〜Zen3世代のCPUは、Intelのマニュアル通りにVPMASKMOVDを実装していることを示した論文を見つけました。手元のRyzen 5 5600 (Zen3世代)もそのように振る舞いました。少なくともZen以降のAMDのCPUは、VPMASKMOVD等をIntelのCPUと同じように振る舞うように実装していると考えてよさそう。たぶん。

話が脇に逸れました。PGO適用時、convolve_horizontally_avx2関数が妙な最適化を施されてしまう問題は、下記の改良型自作ベンチマークテストを実行して気が付きました。改良前は、普段のネットサーフィン(死語)でお目にかかれないような、バカでかい画素数の画像をリサイズするベンチマークテストでした。現実世界をまるで反映していません。反省し、DuckDuckGoの画像検索結果のサムネイルのような、中規模の画素数の画像を想定した設定値をデフォルトにしました。そして独断と偏見で選んだ各種ブラウザで、ベンチマークテストをやり直してみました。

• window.createImageBitmap() Resizing Performance Test

私は、Firefox独自ビルドにPGO (Profile-Guided Optimization)を適用するためのプロファイルデータを集める際、ベンチマークテストの実行に偏るのではなく、実際のサイトを多めに閲覧するなどして、なるべく普段使いの振る舞いをシミュレートするように心がけています。

そのようにして集めたプロファイルデータの中身を見てみると、skia::convolve_horizontallyという関数が頻繁に呼び出されていることが分かります。興味深いことに、この関数はSpeedometer 3.1ではほとんど呼び出されていないようです。ベンチマークテストが現実世界のウェブを模倣しきれていない一例と言えるかもしれません。

このconvolve_horizontallyは、CPUを用いた画像リサイズ処理の一端を担っている関数です。公式Firefox x64版の場合、内部でconvolve_horizontally_sse2という関数を呼び出しています。私の独自ビルドでは以前から、convolve_horizontally_ssse3という独自関数を追加していて、SSSE3に対応したCPU上ではSSE2版比で2.1倍ほど高速に処理を行っています (たぶん)。

今回はこの関数を更に高速化しようと思い、AVX2を用いたconvolve_horizontally_avx2関数を新たに実装して追加してみました。AVX2に対応したCPU上ではこの関数が実行されます。しかし、既にSSSE3版でかなり最適化していたせいか(シャッフルや積和演算命令を使用)、パフォーマンスはSSE2版比で約2.6倍、SSSE3版比で約1.3倍に留まりました。残念。

で、独自ビルドで行ったこれらの最適化の効果を実感できるようなベンチマークテストを作りました。window.createImageBitmap()で画像のリサイズを行った時の時間を計測します。「Start Benchmark」ボタンを押して少々待つと、全ての処理にかかった時間と、各リサイズ処理にかかった時間の中央値が表示されます:

• window.createImageBitmap() Resizing Performance Test

下記がそのベンチマークテストの結果です。いくつかのブラウザの中央値を比較しました。値が小さいほど高速です。テストを行った環境は、Windows 11 24H2、Ryzen 5 5600。テストの設定はデフォルト値を使用。