この HOWTO を書いた後でベンチマークに関係している "落とし穴" と "警告" という言葉の意味を理解し始めました。
Apple と PC の事を言いましょうか ? あまりに明らかで詳細について 言及したくない昔の論争です。筆者は Mac 上のワードプロセッサの負荷を 平均的な Pentium と比べることが本当のベンチマークになる事を疑 っています。Linux と Windows NT 等の起動時間等も同様です。 一つの変更を行った Linux マシンを比較することを可能な限り 努力してください。
一つの例が非常に一般的な間違いを説明します。comp.os.linux.hardware でしばしばみられることは、次のような似た記述があります。: "nnn MHz の XYZ プロセッサを差し込んで linux カーネルをたった i 分 でコンパイル出来ました。" (XYZ, nnn, そして i は必要に応じて読み替 えてください) こいつはいらいらします。なぜなら例えば、メモリの容量、 スワップの容量、同時に動いているタスク、カーネルのバージョン、 モジュールの選択、ハードディスクの種類、gcc のバージョン等の情報が 無いからです。最低、標準的な情報の枠組みを提供している LBT レポート の書式を使用することをお勧めします。
良く知られているプロセッサ製造会社はかつて特別なカスタマイズした gcc で作成したベンチマークの結果を公表しました。倫理的に考えれば これらの結果は標準的なバージョンの gcc を使っている Linux コミュニティでは 100% 意味がありません。同じことは所有者の ハードウェアにも言えます。ベンチマークは既製のハードウェアと フリー (GNU/GPL の考えによる) ソフトウェアにも適応できるからです。
Linux について話しています、いいですね ? 従って他のオペレーティング システムで作成したベンチマークに関しては忘れましょう (これは上記の "リンゴとオレンジを比べる" 所の落とし穴の特別な場合になります)。 また、Web サーバの性能に言及する場合は、FPU 性能や他の重要でない 情報を引き合いに出す必要はありません。このような場合は、 過ぎたるは及ばざるが如しです。また、ご自分の猫の年齢や ご自身の機嫌等にも言及する必要も ありません 。
これは結果の再作成に用います。同じシステムで Z ベンチマークを毎回 実行する場合、かなり違った結果 (> 2 %) を得るでしょう。 その時、Z ベンチマークは十分な精度はでないし、多分再開発する必要も ないでしょう。まだ Z ベンチマークを使用したい場合は結果の変動を はっきりと言及するべきで、むしろ結果の平均の百分率とこれらの変動を 確率的説明に言及するべきでしょう。与えられたベンチマークの分散を 指摘できない場合とできたとしても、特別な警戒について議論 なしに基本的な仮定として分散は 1 % 以下です。
表面上無害な、明白なベンチマーク結果からベンチマークが失敗だという 結論を出す全ての種類の技があります。これは LBT がこのような判断のた めにひとつの Comments 欄がある理由なのです。その時、それぞれの精密 な調査するまでデータをソートする良い考え方がいくつかの結論を出す事 になります。