Google Chrome のバージョンがいつのまにか 53 になっていました。
Google Chrome バージョン 51 から stable なバージョンでプラットフォームに依らず利用可能になった WebAssembly ですが、昨 5 月にそのバージョン 51 で WebAssenbly の機能が有効時と無効時で、JavaScript の ベンチマークを取って結果を比較しました。[1]。
その後も定点観測的に、Google Chrome のバージョンが上がるたびに同じ比較をしようと考えていましたが、いつの間にかバージョンが 53 になってしまいました。バージョン 52 ではできませんでしたが、バージョン 53 で同じように Google の Octane でベンチマークを取って比較してみました。
動作環境は次の通りです。使用した PC は前回と同じです。
- PC: HP Stream 11-r016TU
- OS: Fedora 24 (x86_64)
- Google Chrome バージョン 53.0.2785.116 (64-bit)
ベンチマークの結果にはばらつきがありますので、 Octane を 5 回連続実施して一番高いスコアを残しています。
WebAssembly の有効化｜無効化
Google Chrome のアドレスバーに chrome://flags/#enable-webassembly と入力します。
試験運用版 WebAssembly の行で「有効にする」｜「無効にする」をクリック後、画面下の「今すぐ再起動」をクリックして Google を再起動して機能を有効｜無効にします（右図）。
WebAssembly 無効時
まずは、WebAssembly を無効にした時にベンチマークを 5 回実施した中でベストの結果です。
WebAssembly 有効時
次が、WebAssembly を有効にした時にベンチマークを 5 回実施した中でベストの結果です。
まとめ
Octane の総合スコアでは、WebAssembly を有効にした場合の方が若干高くなっていますが、各項目を較べると、SplayLatency と pdf.js の二項目を除き、パフォーマンスは似たりよったりです。前回確認した時のベストスコアより、どちらのスコアも高くなっているのは、WebAssembly だけでなく、Google Chrome の Javascript エンジンである V8 もまた、改良が続けられているからでしょう。
このベンチマークで確認する限り、今のところ WebAssembly の機能が圧倒的に既存の方法より優れているとは言えません。ひきつづきこのベンチマークを、ある程度定期的に実施していく予定です。
| Default | WebAssmbly Enabled |
change ratio [%] |
|
|---|---|---|---|
| Richards | 9366 | 9087 | -3.02 |
| Deltablue | 16642 | 16053 | -3.60 |
| Crypto | 9708 | 9755 | 0.48 |
| Raytrace | 15656 | 16986 | 8.15 |
| EarleyBoyer | 11618 | 11521 | -0.84 |
| Regexp | 870 | 878 | 0.92 |
| Splay | 6122 | 6250 | 2.07 |
| SplayLatency | 9694 | 11139 | 13.87 |
| NavlerStokes | 11724 | 11961 | 2.00 |
| pdf.js | 3879 | 4394 | 12.45 |
| Mandreel | 5713 | 6194 | 8.08 |
| MandreelLatency | 14408 | 13294 | -8.04 |
| GB Emulator | 17618 | 17660 | 0.24 |
| CodeLoad | 3337 | 3307 | -0.90 |
| Box2DWeb | 10822 | 10871 | 0.45 |
| zlib | 23263 | 23359 | 0.41 |
| Typescript | 7817 | 7800 | -0.22 |
| TOTAL | 8487 | 8651 | 1.91 |
参考サイト
にほんブログ村
0 件のコメント:
コメントを投稿