[論文レビュー] Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

Abhinav Jangda, Bobby Powers+2 more|arXiv (Cornell University)|Jan 25, 2019

Security and Verification in Computing参考文献 19被引用数 47

ひとこと要約

この論文は Browsix-Wasm と Browsix-SPEC を構築し、改変なしの Unix/WebAssembly アプリをブラウザで実行し、大規模な SPEC CPU ベンチマーク評価を実施して、WebAssembly が Chrome で native より 1.55 倍遅く、Firefox で 1.45 倍遅いことを発見し、広いギャップといくつかの効率性の問題を特定した。

ABSTRACT

All major web browsers now support WebAssembly, a low-level bytecode intended to serve as a compilation target for code written in languages like C and C++. A key goal of WebAssembly is performance parity with native code; previous work reports near parity, with many applications compiled to WebAssembly running on average 10% slower than native code. However, this evaluation was limited to a suite of scientific kernels, each consisting of roughly 100 lines of code. Running more substantial applications was not possible because compiling code to WebAssembly is only part of the puzzle: standard Unix APIs are not available in the web browser environment. To address this challenge, we build Browsix-Wasm, a significant extension to Browsix that, for the first time, makes it possible to run unmodified WebAssembly-compiled Unix applications directly inside the browser. We then use Browsix-Wasm to conduct the first large-scale evaluation of the performance of WebAssembly vs. native. Across the SPEC CPU suite of benchmarks, we find a substantial performance gap: applications compiled to WebAssembly run slower by an average of 45% (Firefox) to 55% (Chrome), with peak slowdowns of 2.08x (Firefox) and 2.5x (Chrome). We identify the causes of this performance degradation, some of which are due to missing optimizations and code generation issues, while others are inherent to the WebAssembly platform.

研究の動機と目的

• 未変更の Unix アプリケーションを用いて、ブラウザ上での WebAssembly の大規模で公正なベンチマークを動機づけ、実現する。
• 最小限のオーバーヘッドで、ブラウザ内で WebAssembly でコンパイルされた Unix プログラムを実行する Browsix-Wasm を開発する。
• ブラウザ内で SPEC CPU2006/2017 および PolyBenchC ベンチマークを自動化し、詳細なタイミングとハードウェアカウンタデータを収集する Browsix-SPEC を作成する。
• WebAssembly をネイティブと定量的に比較し、パフォーマンスギャップの根本原因を分析する。
• 実装者に WebAssembly のパフォーマンスギャップを埋めるための実用的な指針を提供する。

提案手法

• 最適化されたカーネル統合を伴い、ブラウザ上で未変更の WebAssembly Unix プログラムを実行するために Browsix を Browsix-Wasm に拡張する。
• ブラウザインスタンスの調整、ベンチマーク資産の管理、SPEC および PolyBenchC のブラウザ内ベンチマーク用のパフォーマンスカウンタを収集する Browsix-SPEC を開発する。
• ベンチマークをネイティブ（Clang）および WebAssembly（Browsix-Wasm）にコンパイルし、ブラウザコードを変更せずに Chrome と Firefox の両方で測定する。
• レジスタ圧力、命令混合、分岐挙動を含む WebAssembly の遅延原因を分析するためにパフォーマンスカウンタを使用する。
• asm.js と比較して WebAssembly の相対的な改善を定量化し、asm.js に対する速度向上の以前の主張を検証する。
• WebAssembly バックエンドの最適化を導くために、実行時間のマトリクスとカウンタに基づく説明を提供する。

実験結果

リサーチクエスチョン

• RQ1 大規模で実世界のベンチマークスイート（SPEC CPU2006/2017）および PolyBenchC において、ブラウザ内の WebAssembly の性能はネイティブコードと比較してどうか？
• RQ2 観測された WebAssembly のネイティブに対する遅延の主な要因は何か（例：レジスタ割り当て、命令数、分岐、メモリ挙動）？
• RQ3 Browsix-Wasm/Browsix-SPEC 自体のオーバーヘッドはどの程度で、性能結論を覆すほどか？
• RQ4 WebAssembly は一貫して asm.js を上回るのか、 Chrome と Firefox の両方でどの程度か？
• RQ5 実装者に対して、WebAssembly-ネイティブの性能ギャップを縮めるための実践的な指針は何か？

主な発見

Benchmark	Native	Google Chrome	Mozilla Firefox
401.bzip2	370 ± 0.6	864 ± 6.4	730 ± 1.3
429.mcf	221 ± 0.1	180 ± 0.9	184 ± 0.6
433.milc	375 ± 2.6	369 ± 0.5	378 ± 0.6
444.namd	271 ± 0.8	369 ± 9.1	373 ± 1.8
445.gobmk	352 ± 2.1	537 ± 0.8	549 ± 3.3
450.soplex	179 ± 3.7	265 ± 1.2	238 ± 0.5
453.povray	110 ± 1.9	275 ± 1.3	229 ± 1.5
458.sjeng	358 ± 1.4	602 ± 2.5	580 ± 2.0
462.libquantum	330 ± 0.8	444 ± 0.2	385 ± 0.8
464.h264ref	389 ± 0.7	807 ± 11.0	733 ± 2.4
470.lbm	209 ± 1.1	248 ± 0.3	249 ± 0.5
473.astar	299 ± 0.5	474 ± 3.5	408 ± 1.0
482.sphinx3	381 ± 7.1	834 ± 1.8	713 ± 3.6
641.leela_s	466 ± 2.7	825 ± 4.6	717 ± 1.2
644.nab_s	2476 ± 11	3639 ± 5.6	3829 ± 6.7

• WebAssembly は Chrome で平均 1.55x、 Firefox で平均 1.45x ネイティブより遅く、ピーク遅延は Chrome で 2.5x、 Firefox で 2.08x まで。
• 15件中7件の SPEC ベンチマークが Chrome でネイティブから 1.5x 以内、Firefox でも同様に 7 件。
• WebAssembly は Chrome で asm.js より平均 1.54x、 Firefox で 1.39x の速度向上を示す；最良ケースの WebAssembly と最良ケースの asm.js を比較すると約 1.3x の速度向上。
• ネイティブと比較して、WebAssembly は読み込み・格納の増加（Chrome: 2.02x 読み込み、2.30x 書き込み；Firefox: 1.92x 読み込み、2.16x 書き込み）、より多くの分岐、より多い命令キャッシュミスを示し、実行が遅くなる要因となっている。
• 行列乘法では、WebAssembly はネイティブの 2x–3.4x 遅く、コード生成とレジスタの使用の非効率を浮き彫りにしている。
• パフォーマンスカウンタ分析は、レジスタ圧力の増大、より悪いレジスタ割り当て（Chrome/Firefox は Clang の greedy graph-coloring に対して linear scan を使用）、および x86 アドレッシングモードの低利用を主要な低下要因として明らかにする。