ベンチマーク専用だとベンチマークにならない

Vodafone fan! ぶろぐ様のベンチマークテストネタで書く、二つ目の記事です。

Sun Microsystems (Java の開発元、リンク先は日本法人)が、東芝と Sun Microsystems が共同作業を行い Vodafone 902T に 携帯電話向けに開発された CLDC HotSpot Implementation を搭載したと発表しました。

私は CLDC HotSpot Implementation にずっと期待していたので、この発表に舞い上がり、どんなベンチマークを走らせようかと考えました。でも、一時間ほど考えて、ベンチマーク専用プログラムでは意味がないことが CLDC HotSpot Implementation の良さなのだと考え直しました。

CLDC HotSpot Implementation の素晴らしいところは、Java のクラスファイルを CPU ネイティブコードにコンパイルし直して最適化まで行うことです。再コンパイルと最適化は一応は別の事柄で、ここでは先に最適化から書きます。

最適化とは、数学を駆使してプログラムの無駄を省く素晴らしい技術です。でも、センセーショナルに書けば、バグが出ない範囲でサボる技術です。

サボったらプログラムがおかしくなるじゃないかとおっしゃるでしょうが、数学を駆使するとバグの出ないサボり方が見つかっちゃうものなんです。二回計算していていつも結果が一緒なら一回しか計算しないとか、計算した結果が実はどこにも使われていないと分かれば最初から計算しないとか。すると計算回数そのものが減るんです。

例えて言うと、一億回計算させるベンチマークプログラムを作ったとして、他の携帯電話は正直に一億回計算するのに、Vodafone 902T は一億回計算していない可能性が大なんです。

次にネイティブコードへのコンパイルとは、Java プログラムのはずが携帯電話の中でネイティブプログラムに入れ替わっているという技術です。これは、プログラムの実行にかかる速度だけなら 10 倍にできます。

でも、数学を駆使してサボり方を見つけたり携帯電話の中でコンパイラを動かしたり、最適化のためには計算がいります。ということでサボろうとすると重くなるのでさじ加減が大事だったりします。携帯電話では簡単なサボり方を、PC では大掛かりなサボり方を、サーバではとんでもないサボり方を、します。

難しい話をすると、CLDC HotSpot Implementation では constant folding と constant propagation と loop peeling だけをしているそうです。私も folding と propagation の区別がついていない生兵法なのですが、先に書いた計算を繰り返さないぐらいの最適化はやるということです。

サーバだとどのくらいサボるかという話は HP (と書けばヒューレット・パッカード社!)が公開しているサーバ向け HotSpot VM の特徴を読むといいです。最後の例で「どうして同じ計算が途中から 2000 倍の速度になるんだ!?」と不思議に思われるでしょう。途中で「プログラムのこの部分は何度も繰り返されるからサボれないか考えよう」と調べ始め、実は計算結果が最初から決まっていることに気付いて思いきりすっ飛ばしてしまったんです。

だとすると、どんなプログラムなら性能を正確にかつ分かりやすくはかれるのか、私には分かりません。サボり方とコンパイルしてこうかがある箇所の組み合わせで、速度が結構変わりそうですから。でも、それは私の考えが浅いからでしょう。なぜなら...

Xengine4j については、逆に見直しました。ソースコードを 15 分読んで私にはボトルネックが分かりませんでしたし、結果が Sun Microsystems 社の宣伝文句に近いですし。宣伝文句に近いということは都合が良いことの裏返しでもあるのですが。

@nifty が DomainKey を送信し始めていた

今日、自分が @nifty のメールアカウントから送信したメールを見たら、ヘッダに DomainKey-Signature が挿入されていました。

DomainKey の技術的検証ができるほど調べていないので訳も分からず信じているだけですが、spam を減らす努力は歓迎します。

酒を飲みつつ説教を聞きます

～vodafone fan! ぶろぐ！～ にて vdfx.net のオフ会を開くという提案がなされました。

あまり vdfx.net に入っていない私ですが、参加していいでしょうか。

一つは、飲ん兵衛だから。

もう一つは、普通の人の意見を聞くため。海外メーカの安い端末があれほどの非難を浴びるとは想像だにしていなかった私は、すっかり打ちのめされ、普通の人の意見を聞かないといけないかと思いました。

ご迷惑であっても、おしかけたいところです。

ベンチマークテストの作り方が分からない

～vodafone fan! ぶろぐ！～に携帯電話上の Java アプリの実行速度を測るベンチマークテストの話が載っていました。使われたベンチマークは Xengine4j というそうです。

私は、ベンチマークテストをどう作っていいか分かりません。でも、どんなベンチマークテストなら実用的なのか分かっている人は少ないと思うのです。

まず省電力モードの存在があります。整数演算が速くてベンチマークテストがすぐに終わるならいいのですが、少し遅くなるとキー入力が無い場合は省電力モードに入ります。するとますます遅くなるので差が開く一方です。ベンチマークテストを走らせる途中でキーを押してみてください。もしかしたら速くなるかもしれません。ちなみに、これは携帯電話のアプリケーションプロセッサが速くなっても思考ルーチンの強い将棋・以後ソフトを作れない理由です。キー入力が無いのにアプリケーションプロセッサを全力で回すとバッテリー消費に際限がなくなっちゃうんですね。

つぎに、実は整数演算を酷使する実用アプリは多いのかという話もあります。ベンチマークテストが普通のアプリより重いなら、普通のアプリは整数演算をあまりしていないのでしょう。すると速度の上限を決めるのは整数演算ではなく描画速度だったりするんです。そうしたら、整数演算を大量に行い描画を少量行う -そして遅いことを印象づける- アプリは実用とかけ離れているおそれも大です。

という訳で、数値が単一でしかでないベンチマークテストをあまり信用しません。Xengine4j は最小値も出るので省電力モードは考慮できるかもしれません。でも一番は、動かしたいアプリ自体でベンチマークテストを行うか測定項目専用のベンチマークソフトを作ることでしょう。

偏屈な人間には鉄槌が下る

Apple Computer が Macintosh の CPU を x86 に転換する事実は、x86 が嫌いで UNIX ノートのつもりで PowerBook G4 を買った私にとても厳しいです。今晩はアパートでやけ酒。