JavaScript ベンチマーク

2010年9月19日(日) 6時44分 by level
B ?

これは JS Benchmarks: Closing In < Rob Sayre's Mozilla Blog の抄訳です。この記事の肝は後半ですので、ベンチマーク結果だけ眺めて帰ることのないように!

JS Benchmarks: Closing In

この記事はいくつかのベンチマークのスコアについて取り上げ、それらが実際に何を測定しているかについて掘り下げます。

Firefox 4 の開発サイクルでは JägerMonkey の導入など JS エンジンの性能向上が著しいので、今こそベンチマーク結果を更新しておく良い機会です。ベンチマークは Windows 7 が動く Lenovo Thinkpad X201 で測定しました。以下は SunSpider ベンチマークで Firefox の成績の改善状況を示しています(数値が小さいほど良い)。

見ての通り、大きな改善があったことが分かります。下の図は競合ブラウザとの比較です。差はかなり縮まっており、今後も改善が予定されています。

Google の V8 ベンチマークでは、Firefox の成績は劇的に改善しています(数値が大きいほど良い)。

以下は競合ブラウザとの V8 の成績の比較です。

以上が現在のベンチマーク結果ですが、近い将来、更新された結果が出てくるでしょう。

これらのテストは何を測定しているのか?

答えは簡単ではありません。これらのベンチマークは JavaScript の実行速度を測定することになっていますが、しばしばとても非現実的な作業について測定することに陥っています。例えば、以下のコードは SunSpider の bitwise-and.js の全体です。

bitwiseAndValue = 4294967296;
for (var i = 0; i < 600000; i++)
    bitwiseAndValue = bitwiseAndValue & i;

このループの実行速度を測定することにどれだけの意味があるのか私にはわかりませんが、Firefox はこれを世界最速で実行します。

現在の多くのベンチマークの問題点は、可能な限り結果をキャッシュしようという誘惑の存在です。それは確かにスコアを向上させますが、非ベンチマークコードではキャッシュがこれ程役に立つケースは非常にまれなのです。例えば、今ではすべてのエンジンは eval 文字列のキャッシュをもっています(我々のコードはここにあります)。このキャッシュは場合によっては実世界のコードでも役に立つこともあります:digg.com などいくつかのサイトではキャッシュにヒットすることが知られています。しかし、SunSpider ではキャッシュは 非常に大きな効果があるために、その重要性があまりに誇張されてしまいます。

我々の抱える別の問題は、多くのベンチマークは実際には何も実行していないということです。そのためとても間違いを犯しやすいのです。Googleの V8 ベンチマークはスプレー木に関する処理を行う splay というテストを持っています。しかし、それは実際のプログラムでは使用されないようなものなので、このテストはいくつかの問題を抱えています。まず、私たちはこのテストはその時間の多くを数値から文字列に変換するのに費やしていることを見つけました。後に、このベンチマークがスプレー木に非現実的なパターンでノードの追加や挿入を行っていることを見つけました。彼らの名誉のために言っておきますが、V8 チームは私たちが問題を発見する前にそれらを解決しました。しかし、これらの問題の根本はベンチマークが現実のプログラムを実行していないことにあるのです。

Mozilla にも悪いテストを書いた責任があります。我々の Dromaeo テストスイートはすべて小さなループと非現実的な処理で構成されています。Dromaeo テストスイートにはそのように作成された正規表現と文字列のテストがありますが、そのいくつかは1要素キャッシュ(one-element cache)の使用を容易にしています。私たちはそれを修正するべきですが、他にも同様の問題がたくさん存在するのです。

最後の問題は特定のテストに対する特殊処理です。私が上記の SunSpider テストを実行したとき、IE9 が math-cordicテストで他のブラウザよりも少なくとも10倍も速い成績を得ることに気が付きました。これは非常に興味深い結果でしたが、どうやらそれは小さな変更には耐えられないようです。私はそのテストに少し修正を加えました: true 行を1行だけ追加したものと(diff)、return 行を1行だけ追加したものです(diff)。ここでこれらの二つのテストを元の math-cordic.js とともに実行することができます。

これら3つのテストは大体同じ実行時間となるはずですが、上のスクリーンショットに示したような結果は何か問題あることを示しています。

Firefox 4 で行った処理速度改善はとても刺激的でした。これからもそうなるでしょう。私たちが行った改善がユーザーの実行するコードを高速化することを願っています。またベンチマークを鍛えることも継続していきます。

以下は、本記事に対する Nicholas Nethercote によるコメント:

Hennessy と Patterson による "Computer Architecture" の第1章はベンチマーク作成者必読だ。彼らはベンチマークを5つのカテゴリーに分類している。ベストからワーストに:

  1. 実アプリケーション
  2. 修正されたアプリケーション(例:CPU 限界を得るための I/O の除去)
  3. カーネル(実アプリケーションの主構成要素)
  4. おもちゃベンチマーク(例:エラトステネスのふるい
  5. 合成されたベンチマーク(特定の処理を測定するために人工的に生成されたコード、例:Dhrystone

SunSpider は多くのおもちゃベンチマークを含んでいる(二つのバージョンのエラトステネスのふるい!)。わずかな実アプリケーションも含んでいるが、あまりに小さすぎる。例えば crypto-md5 はあるテキストの md5sum を計算する。Firefox はそのメインループに非常に良いコードを生成するが、入力テキストがあまりに短いのでコンパイルのオーバーヘッドがあだになり、悪い成績しか残さない(オーバーヘッドは大きくはないが、テストの実行はわずか13msでしかない)。もしテキストサイズが100倍大きければ、我々はたやすくベストスコアを出すはずだ。

同じ要領で SunSpider や V8 ベンチマークの多くをこき下ろすのは簡単だ。

コメント

コメントはありません。

トラックバック

トラックバックは検索対象外です。

この記事にリンクしているページ < >

  1. データがありません。