アーカイブ開いてREADME的なもの探しても無いし、Webkitのサイトやその周りにも載って無いしでよくわからない、ので調べてみた。ウェブブラウザに搭載されているJavaScript処理系がどんだけやれんのか叩き出してくれるアレです。
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
3d-cube
元ネタはここ。
前版よりパフォーマンスが落ちるバグの確認の為のコンテンツだったらしい。
回転する立方体の3Dレンダリング。
3d-raytrace
Apple謹製。レイトレーシングとも言われる、光の当たり方を視線から追っていく像を描く手法。アルゴリズムは単純ながら、膨大な計算量が必要とされる為、Benchmarkにはもってこいのよう。
ちなみに、中のtestOutputというオブジェクトには確認用のHTMLコードが入っているので、これを吐き出すと動かしてみることができる?ようです。
access-fannkuch
元ネタの元ネタは恐らくここ。*PostScriptファイル
1994年にLispニューズグループで議論された、整数と整数ベクトル操作がC言語で書かれたそれの10倍以上遅い、という問題で例示されたコンテンツであるそうです。「fannkuch」はドイツ語でパンケーキのこと?でも翻訳してみたらスルーでした。
access-nbody
N体問題は,複数の粒子が互いに影響を与えあう系の時間発展を求めるシミュレーションであり,このような特徴を持つ問題の1つである。
この問題に対するJSによる解法(アルゴリズム)のひとつ、に見える。
access-nsieve
有名な「エラトステネスの篩(ふるい)」。与えられたnまでに含まれる素数を導くアルゴリズム。ちなみに、中にあるpad()っていう関数使われていないように見えるのだけれど...?
bitops-3bit-bits-in-byte
元ネタはここ。何らかのビット操作で、新しいアルゴリズムを使うとこんなに早くというのを述べているのだけれど、具体的に何を解決するアルゴリズムなのか不明。
bitops-bits-in-byte
で、こっちは上記で比較されている”古い”方。
bitops-bitwise-and
巨大な数に対してひたすら&を掛けていくだけ。
bitops-nsieve-bits
前述の「最速プログラミング言語大会」から。「エラトステネスの篩(ふるい)」を、ビットシフトで実現したものっぽい。たしかに専用のプロセッサ積んでなければ掛け算割り算はシフトでやったほうが速い説。今もそうなのかな。
crypto-aes
Advanced Encryption Standardでロミオとジュリエットの一部分を符号化、複合化。
crypto-md5
MD5(Message Digest Algorithm)で、こちらもロミオとジュリエットの一部分のMD5ハッシュを取得。
date-format-tofte
"1/1/2007 1:11:11"をリフォーマットしまくる。phpのdate関数を模した実装らしい。
date-format-xparb
上のtofteが、日付生成文字に対応する関数を定義しておいて、一気にevalするような実装に対して、こちらは一文字ずつパーズするかんじ。
math-cordic
CORDIC法という三角関数等を計算するときに使えるアルゴリズムのJS実装。まあ、mathって付いてるからその周辺だわな。
math-partial-sums
数列の部分和の計算。らしいのだけれど、具体的にどうすごいのか不明。
部分和問題(数列のある部分の和が与えられたNと一致するかどうか判定する)のアルゴリズム?
math-spectral-norm
浮動小数の配列で表された行列・ベクトルの演算を行う。らしいのだけれど、具体的にどうすご(略)
string-base64
XML-RPCを実装したFirefoxの拡張の中にある、BASE64エンコード部分をそっくりそのままもってきて、中で生成したランダムな数列をBASE64文字列にエンコード。
string-fasta
「ONE Homo sapiens alu」をFASTA形式で吐き出す。FASTA形式とは、”>”記号に続いて配列名称を記載して、その次の行から要素を記載する形式らしい。
string-unpack-code
MochiKit、jQuery、prototypeそれぞれで圧縮されたJSコードを伸張する機能を呼び出したときの時間。なぜ難読化されているのか一瞬いぶかしんだけれどすぐ解決。
string-validate-input
名前や郵便番号(zip-code)を数千回生成して、その妥当性を検証(validate)している。
おわり。…つか…れた…。
結構詳細不明なのがあってごめんなさい。
安易に繰り返すのは意外に少ない印象。JITにも強いのかな。
ブラウザの速さって、別にJS処理系だけで決まるわけではないと思うのですが、有力な指針のひとつである事は確かで、何よりわかりやすいので、よく使われるんだろうなあ。