|
|
次のページ
前のページ
目次へ
2. ベンチマークの手順と結果の解釈
幾つかの若干明白な推奨手順があります。:
2.1 ベンチマークの選択を理解する
合成ベンチマーク対アプリケーションベンチマーク
ベンチマークを雑用として時間に費やす前に、基本的な選択として "合成" ベンチマークと "アプリケーション" ベンチマークのどちらかを選択しま しょう。 合成ベンチマークは特にコンピュータシステムの独立した構成部分の 性能を測定するように設計されています。通常、選択した構成部分の最大 能力を使用します。良く知られた合成ベンチマークは元々は 1972 年に Harold Curnow が FORTRAN でプログラムされた Whetstone スイートで、それにもかかわらず現在でも 普及しています。Whestone スイートは CPU の浮動小数点性能を測定する でしょう。 合成ベンチマークについての主な批判はこのベンチマークがそのコン ピュータシステムの実際の状況での性能を意味するものでは無いという 事です。Whestone スイートを例にあげるとメインループが短く、CPU の 1 次キャッシュに簡単にぴったりはめ込まれてしまい、FPU パイプ ラインを絶えず占有するため、FPU は最高速度で動作します。 25 年前にこのプログラムが作成されたことを考慮するならば、命令の パイプラインの考え方はその頃には存在していません (Whestone ス イートの設計はもっと昔に行われたはずです !)ので、現代の RISC マイクロプロセッサのベンチマークに使うときは、この結果を注意して 解釈することを確認しなければなりません。 他の注意すべき合成ベンチマークの非常に重要な点は、理想的には、 テストしたシステムの特定の様相を伝えるものであり、他の様相 とは独立しています。イーサネットカードの入出力スループット は4 M バイトメモリの 386SX-16 で実行しても 64 M バイトメモリの Pentium 200 MMX で実行しても同じか同様の数値になります。別な方法では、 CPU/マザーボード/バス/イーサネットカード/メモリサブシステム/DMA の 組み合わせ全てにわたって測定するテストです。イーサネットカードの変更 よりも CPU の変更の方が大きいので全然使い物になりません。もちろん、 同じカーネルとドライバの組み合わせで行ってもより大きな変動が起こりま す。 最後に、とても一般的な間違いは色々な合成ベンチマークの平均をとること と、このようにして得た平均がそのシステムに対する実際の性能の良い表現 であると主張することです。結果は二つの非常に異なる理由から使えません。
ここでは Cyrix Corp. の許可を受けて Web サイトを引用して FPU ベンチ マークに対するコメントとします。: "浮動小数点ユニット (FPU) は浮動小数点計算を使用するソフト ウェアをより高性能化します。CAD プログラム、スプレッドシート、 3D ゲームと 3D 設計アプリケーションが代表的なものです。しかしながら、 今日の殆んどの一般的な PC アプリケーションは浮動小数点と整数命令の 両方を使っています。結果的に、Cyrix は 6x86 プロセッサの設計において これら 2 種類の命令が混在しているソフトウェアを高速化する為に "並行化" を強調することを選択しました。
x86 の浮動小数点例外モデルは浮動小数点命令を実行中に整数 命令を発行し完了することを許しています。2 回目の浮動小数点命令は前の 浮動小数点命令の実行中は実行開始できません。浮動小数点例外モデルに よって引き起こされた性能限界を取り除くには、6x86 が整数命令の実行中 でも推論的に FPU に内蔵した 4 つの浮動小数点命令を発行できるように しました。例えば、2 つの浮動小数点命令 (FLT) の次に 6 つの整数命令 (INT)、続いて 2 つの FLT を順番に実行するプログラムの場合は、 6x86 プロセッサは全ての 10 個の命令が、最初の FLT の完了前に適切な 実行ユニットに対して発行できます。実行誤りが無い場合 (典型的な場合) は整数ユニットと浮動小数点ユニットの両方が命令を並列に完了します。 実行誤り (異常な場合) が一つでもあれば、推論的な 6x86 の実行性能は このような方法では x86 の浮動小数点例外モデルと変らない所まで低く なってしまいます。
ベンチマークテストの調査は、純粋な浮動小数点だけの合成 浮動小数点ベンチマークは実世界のアプリケーションには無いものである ということを明らかにしました。このタイプのベンチマークは 6x86 プロセッサの実行能力の推測には役に立ちません。Cyrix は非合成な 実世界のアプリケーションを基礎にしたベンチマークの方が実際の優秀な ユーザの仕事をより反映すると思っています。実世界のアプリケーション は整数と浮動小数点命令の混在したものなので、従って 6x86 の推測的 実行性能が役立つのです。" 実際、最近のベンチマークの傾向は一般のアプリケーションを選択し、 完全なコンピュータシステムの性能をテストするのにアプリケーション を用います。例えば、SPECです。良く知られた SPECint と SPECfp の合成ベンチマークスイートを設計した非営利団体 SPEC が、新しいアプリケーションベンチマークスイートの プロジェクトに乗り出しました。しかし又、SPEC ベンチマークが GPL に従うコードに含まれるのは非常に好ましくありません。 LBT 内に含まれるテストを LBT 以外のほかの場所から探してこなければ いけなくなるからです。 要約すると、合成ベンチマークはそれらの目的と限界を理解すれば役に立ち ます。アプリケーションベンチマークはコンピュータシステムの性能をより 良く反映するものですが、Linux システム用の標準的なアプリケーション ベンチマークスイートは利用できるものはありません。
ユーザレベル 対 マシンレベル ベンチマーク
マシンレベルベンチマークはハードウェアの性能を直接測定するものです。 測定するものは CPU クロック、DRAM メモリとキャッシュ SRAM のサイクル 時間、バードディスクアクセス時間、潜在時間とトラック間移動時間等々、 です。これらはシステムを買った時やどんな部品でシステムが構築されて いるか不思議に思ったときに有効です。しかしの部品を調査するより良い 方法は、マイクロコンピュータのふたを開けてどんな部品があるか数え上げ、 何とかしてそれぞれの部品のデータシートの一覧を得る方が有効です。 通常 インターネット を用います。 他にマシンレベルベンチマークのより良い使用方法はカーネルドライバが 正しくハードウェアの仕様通りに構成されているかチェックする事です。 これは部品のデータシートを持っている場合、マシンレベルベンチマーク の結果と理論上の製造者の仕様とを比較できます。 ユーザレベルベンチマークはマイクロコンピュータの特定の角度から見た ハードウェア/ドライバ/OS/コンパイラ の組み合わせに関係しています。 例えば、ファイル入出力性能とか特定のハードウェア/ドライバ/OS/ コンパイラ/アプリケーションの性能をみます。つまり色々なマイクロ コンピュータ上での特定の Web サーバパッケージのベンチマークや同じ プラットフォーム上での色々な Web サーバパッケージのベンチマーク 等です。
2.2 Linux で可能な標準ベンチマーク
カーネルのコンパイル
個人的な意見ですが、Linux マシンの部品を交換して改善したとき だれでも実行できる簡単なテストはカーネルのコンパイルを起動する ことです。ハード/ソフトウェアの改善前と後の時間を比較してみましょ う。その他の条件を同じにして(つまり例えばカーネルの設定を変えない 場合)おかないとコンパイル性能の測定は役に 立ちません。よって、その次のような言い方が自信をもって言えるで しょう。 "A を B に変更したらそのシステムとその条件で Linux のカーネルのコンパイル時間が x % 向上した"。 それ以上でもなく、それ以下でもありません。 カーネルのコンパイルは Linux の下では普通に経験する作業で、殆んどの 関数が使用されるので (浮動小数点性能を除く) 通常のベンチマークに使用 されます。かなり良い個体テストという性質があります。殆んどの 場合、他の Linux ユーザがこのようなテストで同じ結果を再現できない その理由はハード/ソフトウェアの構成が色々あるのと、この種のテストが 異なるシステム間の比較に使う "ものさし" が無いことです。(我々全員 が標準的カーネルをコンパイルする場合を除きます - 後述参照のこと)。
Linux 固有のベンチマークツール
Linux 固有のベンチマークツールは未だありません。しかしながら、多く の Unix ベンチマークツールがあります。例えば、 David C. Niemi によって改良され、更新されている Byte Unix Benchmarks も 一緒に置いてあります。これは以前のバージョンと混乱しないように UnixBench 4.10 と呼ばれています。ここに David が行った変更点につい て書いています。: "原作と若干変更した BYTE Unix ベンチマーク は まったく当てにならないシステム性能の指標を示す数多くの ふるまいで止まってしまいます。故意に "指標" の値を古いベンチマーク の混乱を避けるようにかなり異なったものにしています。" Byte Linux Benchmarks は David が 1991 年 5 月 にさかのぼった Byte Unix Benchmarks を少々変更したもの (Linux 用の変更は Jon Tombs が行い、原著者は Ben Smith, Rick Grehan と Tom Yager) です。 Byte Linux Benchmarks 用は中央に Web サイト がありますが、新しい UnixBench ベンチマークを使用して開始する ことをお勧めします。Unixbench について質問がある場合は Linux と その他の OS についてのベンチマークに関する検討を行う ように設定したメーリングリストを通じて David に連絡することを 提案します。"subscribe bench" というメッセージの本文を majordomo@wauug.erols.com に送付して参加して下さい。 また最近、 Uwe F. Mayer が BYTE Bytemark スイートを Linux に移植しまし た。これは最新のスイートで Rick Greha により BYTE Magazine がテスト した最新のマイクロコンピュータシステムの CPU, FPU と メモリシステム の性能と一緒に苦心して置いてあります。(厳密に言えばこれらの ベンチマークはマイクロプロセッサ性能よりのベンチマークで、入出力とか システム性能とかは勘定に入っていません。) Uwe はまた Web サイト に Linux BYTEmark ベンチマークの 彼のバージョンでのテスト結果のデータベースがあります。 X サーバとグラフィックカードの相対的な性能をテストするには、 Claus Gittinger による xbench-0.2 スイートが sunsite.unc.edu, ftp.x.org と その他のサイトから利用可能です。どちらかといえば古く 個人的には最近の加速化された X サーバの性能を正しく反映していない と思います。 Xi Graphics の Jeremy Chatfield の意見を引用します。: " 最近のベンチマークは多くの弱点があります。例えば、"ユーザ 応答性" つまり、ユーザがマウスやキーボードの変更に対する画面の応答 速度がどれくらい速いのかという事を示すことができません。 一つの代表的なベンチマークはテキストを良く使う人の需要とか、 X サーバ上でグラフィックスプリミティブからイメージを作成する人とは 別に予め計算されたグラフィックを良く使う人以外には助けにはなりませ ん。ほとんどの現在のベンチマークはマザーボードの メモリ->ホスト-CPU->PCI チップセット-> グラフィックボード の帯域幅を表示するものです。これは一つの数値 *です* が、 高速化された X サーバを反映するものではありません。" Xfree86.org は (賢明にも) 如何なるベンチマークも保持および推奨も 辞退しています。 XFree86-ベンチマーク調査は xbench の結果のデータベースを 置いている Web サイトです。 純粋なディスク入出力のスループットについては hdparm プログラム (殆んどの配布物に含まれていますが、sunsite.unc.edu からも 入手可能です) は -t と -T オプションをつけて実行すると 転送速度を測定できます。これは典型的なマシンレベルベンチマークです。 他に色々な角度から Linux マシンの性能をテストするフリーなツールが インターネットで入手可能です。Linux ベンチマークプロジェクト Web サイト にほとんど全てのリンクがあります。このサイトは Washington Area Unix Users Group がインタネット上で Linux 用の中央貯蔵所として特定用途に設定して います。しかしながらまだまだ作業中です。
2.3 その他のリンク情報と参考文献
Dave Sill による comp.benchmarks FAQ はベンチマークについての 標準的な参考文献です。Linux 特有ではありませんが、ベンチマークに ついてまじめに取り組むすべての人に読むことをお勧めします。 幾つかの FTP や Web サイトと 46 の種々のベンチマーク の一覧がそれぞれの保持先のリンク情報と一緒に含まれています。 全てのベンチマークは無料で利用可能でないです。幾つかはかなり高価 (例えば SPEC への参加は有料) で、幾つかは GPL に準拠しています。 筆者は comp.benchmarks FAQ が言及しているベンチマークのそれぞれ の調査は出来ませんが、筆者が 批評したい Larry McVoy による lmbench スイート に最低 1 つのマシンレベルスイートがあります。David C. Niemi の言葉 を引用します。: "Linus と David Miller は幾つかの有用なマシンレベルの測定 とネットワークスループットの測定と 2 つのマシンでテストしたときの ネットワーク潜伏時間の測定に使っています。しかし、全てが "価値ある 数字" ようにはならないと思います。" Alfred Aburto によるかなりまとまっていて 無料で 利用できる FTP サイト があります。LBT に使用していた Whetstone スイートがこのサイトにあります。 comp.benchmarks に定期的に投稿されている Eugene Miya による 長編の複数編にわたる FAQ があります。これは大変面白く、 雨の日に読むのに良いでしょう。次の引用をせずにはいられません: ベンチまーけてぃんぐ: The Art of Selling Inferior Goods インテリア商品の営業の技巧 より John L. Larson CSRD, University of Illinois at Urbana-Champaign ... 技法 8 - 一定に保たないこと * アセンブラのライブラリルーチンを使用してマトリックス乗算を 行う A を使用する * FORTRAN を流用して計算する B を使用する * 性能測定をする * 結論: A が B より高速である * 推論: 林檎とオレンジは両方とも果実である 技法 9 - A で得たことと最新の B で得たことを比較する * A が 3 年間利用できることが知られている * B をベンチマークする * 実行速度を比較する * 結論: A が B より高速である * 推論: 明日の問題は昨日解決している 技法 10 - A と B の先輩を比較する * A をベンチマークする * Illiac I でのベンチマークの記事から性能表を思い出す * 性能を比較する
* 結論: A は HAL-9000 より高速である * 推論: イリノイ大にある全てのマシンは遅い
次のページ 前のページ 目次へ |
[ |