はじめに
"言ってはいけないことは沈黙に置き去りにしなければならない。"
Ludwig Wittgenstein (1889-1951), オーストリアの哲学者
ベンチマークとは計算処理の速度を 測定 したもので、色々な
ハードウェアとソフトウェアのシステム設定の比較に用いられます。
ベンチマークは
ユーザの使いやすさや、美的感覚、人間工学的検討や他の主観的な意見
には関係がありません。
ベンチマークは退屈で反復の多い作業で細部に注意を喚起するものです。
かなり頻繁にその結果は期待に反するもので、(ベンチマークの手順の
殆んど重要な部分を占める) 解釈の題材になります。
最終的に、ベンチマークは意見や近似値ではなく事実と数値を扱います。
ベンチマークは何故そんなに重要なのか ?
意思決定
BogoMips Mini-HOWTO (セクション 8, 第 2 段落) に指摘される理由とは
別に、時折、Linux マシンにかけられる限られた予算と/又は最低限の性能
要求に直面する場合にベンチマークは重要です。言い換えれば、次の質問を
対比することになります。:
- 与えられた予算内で性能はどうしたら最大にできるか ?
- 最低性能要求の水準の為の費用を如何に最小にできるか ?
- (与えられた予算または与えられた性能要件内で) 最高の性能/費用
比をどうしたら得られるか ?
ベンチマークを調査、比較、作成しなければなりません。
性能要件が無い場合、通常 (ガレージにあるような古い 386SX-16 マシンに
相当する) 残りの部品で組んだベンチマークの必要のないマシンの費用の
最小化と、費用の制限がない場合の最大性能のマシンについての性能の
最大化の作業は実世界にはありません。
(皮カバーのかかった電源装置が回りに置いてある Cray マシンは
個人の居間に置くには魅力的ですがこのような事は除きます。)
このようなベンチマークは無意味で時間と金の無駄です。例えば 2 つ 3 つの
内から選択しなければならない場合など決定過程の一部としてしか意味があり
ません。
コンピュータシステムの可用性、客への対応、信頼性、戦略的理由や
その他合理性のある測定可能な特徴づけ等がありますが、
通常、決定過程における他のパラメータは費用です。
色々なカーネルのバージョンの性能を比較するとき、例えば
安定性 は 常に 速度より重要です。
Linux の進歩
Linux は常により効率よく、Unix に互換性のある実装に向けて進化している
ので、種々のアルゴリズム (ハードディスクのアクセス、タスクスケジュー
ル等) での効率性と安定性を測定したくなるでしょう。ベンチマークは
ボトルネックを発見したり、失敗する条件 (例えば負荷が重い場合) の
可能性を発見するのに役に立つでしょう。
無効なベンチマークの検討
残念ながら、ニュースグループやメーリングリストで良く見られる事に:
- 製造者の評判 (測定不可能で意味がありません)
- 製造者の市場占有率 (意味がなく不適切です)
- 不合理な要因 (例えば、迷信とか偏見 :
131313Z というプロセッサを買ってピンクに塗りました ? とかね)
- 誇大な宣伝: 筆者が思うに最悪です。個人的には "humhumhum
inside" とか "kkkkkws compatible" というロゴにはうんざりしています。
(今では "aaaaaPowered" が流行っているけど、次はなんでしょう ?)
こんなキャンペーンに巨額の費用を費やすぐらいなら、新しくて速く
て (安くて :-) バグのないプロセッサを作った方がよろしいでしょう。
誇大な宣伝を止めて、このマザーボードに差してある新しいプロセッサ
の FPU の浮動小数点のバグを取るか若しくは再開発するプロセッサと
交換するかが良いでしょう。
- "お金を払って欲しいものを手にいれる" という意見はごもっとも
です。
冷静で、現実的な事実 を教えてください。
ベンチマークの手順と結果の解釈
幾つかの若干明白な推奨手順があります。:
- 最初でかつ主要部分はベンチマークの目的を確認しましょう。
本当にベンチマークしたいのは何でしょう ? ベンチマークの過程の最後の
意思決定や進化する Linux で何を決定したいのでしょう ?
ベンチマークの成果を得るのにどれくらいの時間と資源をかけられますか ?
- 標準的なツールを使いましょう。最新で、安定版のカーネ
ル版で、標準的な最新の gcc と libc で (例えば、Linux Benchmarking
Toolkit) のような標準的なベンチマークを行いましょう。
- お手元の (例えば、LBT レポートの書式の) セットアップについて
完全な説明をしましょう。
- 一つの変更点だけ分離してみてください。あらゆる所で、
相対的なベンチマークは "絶対的な" ベンチマークより有益です。
そんなに筆者は強制できません。
- 結果を検証してください。出来れば、数回ベンチマークを
実行し、結果の変動を検証してください。説明できない変動があれば無効な
ベンチマーク結果という事です。
- ベンチマークの成果が意味のある情報を含んでいると考えたら、
正確かつ簡潔に Linux コミュニティーで情報を共有
しましょう。
- BogoMips については忘れてください。筆者自身に誓って、
いつか BogoMips ループ用の超高速の ASIC を実装します。そのとき我々は
何を見ているか分かるでしょう。
ベンチマークの選択を理解する
合成ベンチマーク対アプリケーションベンチマーク
ベンチマークを雑用として時間に費やす前に、基本的な選択として "合成"
ベンチマークと "アプリケーション" ベンチマークのどちらかを選択しま
しょう。
合成ベンチマークは特にコンピュータシステムの独立した構成部分の
性能を測定するように設計されています。通常、選択した構成部分の最大
能力を使用します。良く知られた合成ベンチマークは元々は 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 サーバパッケージのベンチマーク
等です。
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 用は中央に がありますが、新しい UnixBench ベンチマークを使用して開始する
ことをお勧めします。Unixbench について質問がある場合は
Linux と その他の OS についてのベンチマークに関する検討を行う
ように設定したメーリングリストを通じて David に連絡することを
提案します。"subscribe bench" というメッセージの本文を
に送付して参加して下さい。
また最近、 が BYTE Bytemark スイートを Linux に移植しまし
た。これは最新のスイートで Rick Greha により BYTE Magazine がテスト
した最新のマイクロコンピュータシステムの CPU, FPU と メモリシステム
の性能と一緒に苦心して置いてあります。(厳密に言えばこれらの
ベンチマークはマイクロプロセッサ性能よりのベンチマークで、入出力とか
システム性能とかは勘定に入っていません。)
Uwe はまた に 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 は (賢明にも) 如何なるベンチマークも保持および推奨も
辞退しています。
は xbench の結果のデータベースを
置いている Web サイトです。
純粋なディスク入出力のスループットについては hdparm プログラム
(殆んどの配布物に含まれていますが、sunsite.unc.edu からも
入手可能です) は -t と -T オプションをつけて実行すると
転送速度を測定できます。これは典型的なマシンレベルベンチマークです。
他に色々な角度から Linux マシンの性能をテストするフリーなツールが
インターネットで入手可能です。Linux ベンチマークプロジェクト
にほとんど全てのリンクがあります。このサイトは がインタネット上で Linux 用の中央貯蔵所として特定用途に設定して
います。しかしながらまだまだ作業中です。
その他のリンク情報と参考文献
Dave Sill による はベンチマークについての
標準的な参考文献です。Linux 特有ではありませんが、ベンチマークに
ついてまじめに取り組むすべての人に読むことをお勧めします。
幾つかの FTP や Web サイトと 46 の種々のベンチマーク
の一覧がそれぞれの保持先のリンク情報と一緒に含まれています。
全てのベンチマークは無料で利用可能でないです。幾つかはかなり高価
(例えば SPEC への参加は有料) で、幾つかは GPL に準拠しています。
筆者は comp.benchmarks FAQ が言及しているベンチマークのそれぞれ
の調査は出来ませんが、筆者が 批評したい Larry McVoy による
に最低 1 つのマシンレベルスイートがあります。David C. Niemi の言葉
を引用します。:
"Linus と David Miller は幾つかの有用なマシンレベルの測定
とネットワークスループットの測定と 2 つのマシンでテストしたときの
ネットワーク潜伏時間の測定に使っています。しかし、全てが "価値ある
数字" ようにはならないと思います。"
Alfred Aburto によるかなりまとまっていて 無料で 利用できる
があります。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 より高速である
* 推論: イリノイ大にある全てのマシンは遅い
Linux ベンチマーク ツールキット (LBT)
Linux 用の基本的なベンチマークツールキットの拡張と改良の為の提案
です。これに価値があるかお手にとって下さい。つまり、作業中という
ことです。これが効果的なテストスイートではないと思ったら
気軽に提案を電子メールで筆者宛てに送付してください。出来るだけ
喜んで変更と改良を行うでしょう。とはいっても議論に入る前に、この
HOWTO とここで述べた参考文献を読んでください。情報のある批評は
歓迎しますが、中身のない批評は歓迎できません。
理論的根拠
まさに一般常識ですが:
- ベンチマークは一日中実行するべきものではありません。比較ベンチ
マーク (色々実行します) の場合は、だれもそのシステムの最速の設定を
決定するのに何日も努力したくはありません。理想的には、すべての
ベンチマーク一式を平均的なマシンと比較するのに 15 分程度かかるで
しょう。
- 明らかな理由で、LBT で使用しているソフトウェアのすべての
ソースコードは自由にインターネットで利用できなければなりません。
多分、GNU/GPL ライセンスに準拠するでしょう。
- ベンチマークは測定した性能を簡単な数値で提供するべきです。
- 合成ベンチマークとアプリケーションベンチマークの混合物
であるべきです(もちろん分離した結果と共に)。
- 合成 ベンチマークのそれぞれは個々のシステムの
最大容量を使用するべきです。
- 合成 ベンチマークの複数の結果を一つの価値ある数値
に平均してはいけません。合成ベンチマーク全体の考え方を
無視できない程の情報の損失を伴って失敗します。
- アプリケーションベンチマークは Linux システム上で一般に動作
するタスクであるべきです。
- 結果の分散は同じマシンで同一もしくは同様の負荷状況で継続的
に実行した場合、 1 か 2 % より小さいでしょう。殆んどの
ベンチマークでは説得力のある必要条件であることに注意してください。
ベンチマークの選択
できるだけテストの重複を避けるように 5 つの色々なベンチマーク
を選択しました。:
- Kernel 2.0.0 (標準構成) の gcc によるコンパイル。
- David C. Niemi による UnixBench ベンチマーク バージョン 4.10。
このバージョンの UnixBench は Double Precision Whetstone テストを
含んでいます。
- Kazuhiko Shutoh による Xengine 1.0 。
- Uwe Mayer により変更された BYTE Magazine の BYTEmark ベンチ
マークのベータリリース 2 。
テスト存続期間
- Kernel 2.0.0 コンパイル: 5 - 30 分、システムの真の
性能に依存します。
- UnixBench ベンチマーク バージョン 4.10: 推定 15 分。
- Xengine: 5 秒。
- BYTEmark ベンチマーク: 推定: 10 分。
コメント
Kernel 2.0.0 コンパイル:
- 何ものか: LBT 内の唯一のアプリケーションベンチマーク。
- コードは広く入手可能 (例えば 古い Linux CD-ROM に見つかります)。
- ほとんどの Lunuxer は極めてよくカーネルをリコンパイルします。
従って、これは全体的な性能の意義深い測定です。
- カーネルは巨大で gcc はどっさりメモリを使用します。小さなテスト
では L2 キャッシュの大きさを減らしてしまいます。
- たびたびディスクへ入出力を行います。
- テスト手順: パッチなど当ってないきれいな 2.0.0 のソースを入手し
て標準のオプションでコンパイルしましょう。エンターキーを繰り返し押し
て make config を行います。報告する時間はコンパイルにかかった時間で
す。例えば make zImage の時間です。make dep,
make clean の
時間は含めないで下さい。カーネルの標準のターゲットアーキテ
クチャは i386 です。これ以外のアーキテクチャのマシンでコンパイルを
行うときは gcc をターゲットを i386 にしたクロスコンパイルの設定に
する必要があります。(gcc のクロスコンパイル用の適切なスイッチに
ついてはオンラインマニュアルを見てください)
- 結果: コンパイル時間を分と秒で計算してください。
(Linux マシンが 30 秒以下のテスト結果を出すまでは秒の端数 (小数点
以下) は報告しないでください。)
UnixBench version 4.10:
- 何ものか: Unix 全体の性能を測定する合成ベンチマーク。
このテストは FPU, ファイル入出力とカーネルのマルチタスキングを働かせ
ます。David Niemi が倍精度の Whetstone FPU テストを原作の FPU テスト
の代わりに UnixBench 4.10 の該当部分に実装しています。
- テスト手順: -O2 をつけて make しましょう
。 ./Run -1 ./results/報告ファイル名 としてテストを起動して
ください。
EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT,
PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS と
SYSTEM CALL OVERHEAD の指標の幾何平均を計算します。
- 結果: 浮動小数点性能とシステムの指標です。
Xengine:
- 何ものか: CPU / ビデオメモリの帯域幅 / X サーバの性能
の高レベルのテストです。
- 小さな X window 内で 4 サイクルエンジンの動作のシミュレーショ
ンを行なうすてきな、見た目の良い、ユーモアのあるプログラムです。
- LBT の中で一番小さく一番短いテストです。
- テスト手順: xmkmf で当該システム用の makefile を作成して、-O2
をつけて ( コンパイルの警告を無視して) コンパイルしてください。
筆者は筆者のシステム用にソースを少し修正する必要がありました。:
a) XtGetValues 関数を呼んでいる行をコメントにしました。;
b) エンジンの横と縦の大きさを次の 2 行で 200 という固定値を指定しま
しょう。
- 結果: RPM の値。
- 注意: このテストは X サーバの性能の厳密で、完璧なテストを意味
するものではありません。しかしながら、システムが画面上にカラーの
画素を出力する速度がどれくらい速いかの指標を得ます。知りたい事の
最小部分ではないでしょうか ?
BYTE マガジンの BYTEmark ベンチマーク:
- 何ものか: CPU 性能の良い測定を提供します。文書から
引用します。: "これらのベンチマークはシステムの CPU, FPU, と
メモリアーキテクチャ の理論上な上限をあばく事を意味します。ビデオ,
ディスク, ネットワークスループットは測定できません。
(これは異なるベンチマークの領域です。)
従って、これらのテスト結果をシステムの評価の全部ではなく
一部として使いましょう。"
- Whetstone テストが丁度 UnixBench 4.10 に含まれる FPU 性能を
表わしているので、FPU テスト結果は処分しました。
- 整数テストは 2 つのグループに分けましょう。これらは
メモリキャッシュ-CPU 性能とそれらに関係する CPU 整数命令を表して
います。
- テスト手順: -O2 をつけて make しましょう。./nbench
> myresults.dat 等としてテストを起動してください。
そのとき、myresults.dat から STRING SORT, ASSIGNMENT と BITFIELD
のテスト指標の幾何学平均を計算しましょう。これはメモリの指標
です。NUMERIC SORT, IDEA, HUFFMAN と FP EMULATION テスト指標の
幾何学平均を計算しましょう。これは 整数の指標 です。
- 結果: メモリの指標と整数の指標の計算は上記で説明
しました。
考えられる改善
理想的なベンチマークスイートは各サブシステム別の合成ベンチマーク
と、異なるアプリケーション用の結果を得るアプリケーション
ベンチマークを数分で実行するでしょう。そのベンチマークスイート
は自動的に全てのレポートを作成し、最終的にレポートを Web 上の中央の
データベースに電子メールを送付し、更新するでしょう。
我々は今までまったく OS 間の移植性について興味を持っていませんでした
が、ごく最近 Linux のバージョン (> 2.0.0) と各種プラットフォーム
(i386, Alpha, Sparc 等) で少なくとも実行できます。
テストはまたとても不便な "特徴" を持っています。: UnixBench と
BYTEmark テストの指標は異なる参考マシンを基にしています。それぞれの
テストの結果を無効に出来ないことにいらいらします。
次の領域は改良のために必要です。:
- ネットワークベンチマーク: 単純、簡単で信頼できる方法で短時間
(設定から実行までで 30 分以下で)のテストネットワーク性能の
ベンチマークについての着想をお持ちの方は、筆者まで連絡下さい。
- X ベンチマーク: X 用のアクセラレータ関数を働かせるには
真の 8, 16, 24 と 32 ビットが必要です。
- Web サーバベンチマーク: 殆んどの Linux ユーザは商用の PC 機材 +
Linux + Apache サーバデーモンで汎用目的の Web サーバを実現しています
が、そのようなマシンでのベンチマークは異なる性能の指標を示します。
WebStone 2.01 は良い候補だと思います。
- ゲーム性能: Doom とか Quake のベンチマークは興味があるでしょう。
筆者は Quake が Pentium 用に手による最適化コードが含まれていると聞いて
いて Linux システムの汎用目的のベンチマークには向かないので、 Doom
ベンチマークの準備をしています。Doom と Quake の基本的な問題はソース
が利用可能でないことです。
LBT レポートの書式
このテスト以外にも、設定を説明している書式なしではベンチマーク手順
は完全ではありません。よって、ここに示します。(次は
comp.benchmarks FAQ からのガイドラインです)
LINUX BENCHMARKING TOOLKIT REPORT FORM
CPU
===
Vendor:
Model:
Core clock:
Motherboard vendor:
Mbd. model:
Mbd. chipset:
Bus type:
Bus clock:
Cache total:
Cache type/speed:
SMP (number of processors):
RAM
===
Total:
Type:
Speed:
Disk
====
Vendor:
Model:
Size:
Interface:
Driver/Settings:
Video board
===========
Vendor:
Model:
Bus:
Video RAM type:
Video RAM total:
X server vendor:
X server version:
X server chipset choice:
Resolution/vert. refresh rate:
Color depth:
Kernel
======
Version:
Swap size:
gcc
===
Version:
Options:
libc version:
Test notes
==========
RESULTS
========
Linux kernel 2.0.0 Compilation Time: (minutes and seconds)
Whetstone Double Precision (FPU) INDEX: (report both the result in
MWIPS and the index)
Unixbench 4.10 system INDEX:
Xengine: (results are in RPM)
BYTEmark integer INDEX:
BYTEmark memory INDEX:
Comments*
=========
* This field is included for possible interpretations of the results,
and as
such, it is optional. It could be the most significant part of your
report,
though, specially if you are doing comparative benchmarking.
ネットワーク性能テスト
ネットワーク性能のテストは、最低 2 つのマシン (サーバとクライアント)
を必要とするので 2 回設定し、たくさん管理するための数値を設定等しま
しょう。TCP/IP イーサネットネットワーク上では、最高の選択は ttcp
パッケージだと思います。若しくは netperf かもしれません。
Symmetric Multi Processing (SMP) 対称型マルチプロセッサテスト
SMP テストはもう一つの挑戦です。SMP 用に特有に設計したベンチマーク
は実用になるマルチプロセッシングの優位性を発揮するアルゴリズムを
開発するのが困難なので SMP 自身を調査するのが困難な期間がありました。
Linux はユニ(単一)プロセッサ(UP) OS として開始しましたが、Linux
カーネルの最新版 (大体 > 2.1.30)では "きめ細かい" マルチプロ
セッシングを行いますが、今の段階ではこれ以上の情報はありません。
David Niemi によれば、" ... shell8 が SMP と UP モードの
類似したハードウェア/OS を比較するのに良い仕事をします。"
例題の実行と結果
自宅の自作ペンティアムマシンで LBT を実行し、そしてこの HOWTO を書き
ました。これはこのシステムの LBT レポートの書式です。:
LINUX BENCHMARKING TOOLKIT REPORT FORM
CPU
===
Vendor: Cyrix/IBM
Model: 6x86L P166+
Core clock: 133 MHz
Motherboard vendor: Elite Computer Systems (ECS)
Mbd. model: P5VX-Be
Mbd. chipset: Intel VX
Bus type: PCI
Bus clock: 33 MHz
Cache total: 256 KB
Cache type/speed: Pipeline burst 6 ns
SMP (number of processors): 1
RAM
===
Total: 32 MB
Type: EDO SIMMs
Speed: 60 ns
Disk
====
Vendor: IBM
Model: IBM-DAQA-33240
Size: 3.2 GB
Interface: EIDE
Driver/Settings: Bus Master DMA mode 2
Video board
===========
Vendor: Generic S3
Model: Trio64-V2
Bus: PCI
Video RAM type: 60 ns EDO DRAM
Video RAM total: 2 MB
X server vendor: XFree86
X server version: 3.3
X server chipset choice: S3 accelerated
Resolution/vert. refresh rate: 1152x864 @ 70 Hz
Color depth: 16 bits
Kernel
======
Version: 2.0.29
Swap size: 64 MB
gcc
===
Version: 2.7.2.1
Options: -O2
libc version: 5.4.23
Test notes
==========
Very light load. The above tests were run with some of the
special
Cyrix/IBM 6x86 features enabled with the setx86 program: fast ADS,
fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem.
RESULTS
========
Linux kernel 2.0.0 Compilation Time: 7m12s
Whetstone Double Precision (FPU) INDEX: 50.2 MWIPS -> 9.2
index
UnixBench 4.10 system INDEX: 58.4
Xengine: 790 RPM.
BYTEmark integer INDEX: 1.50
BYTEmark memory INDEX: 2.50
Comments
=========
均質的な性能の家庭用かつ/または Linux 開発を行うのには
申し分なく、たいへん安定なシステムです。6x86MX プロセッサについて
出来るだけ自分の手で行って結果を報告します !
ベンチマークの落とし穴と警告
この 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 欄がある理由なのです。その時、それぞれの精密
な調査するまでデータをソートする良い考え方がいくつかの結論を出す事
になります。
FAQ
Q1.Linux と ... (他の OS を選択して) どのように性能比較
したら良いでしょう ?
A: Linux と他の OS の性能を比較することは
comp.os.linux.advocacy で感情的な戦いの議論をはじめるのに良い
方法です。[訳注:感情的な戦いは好ましくないので逆説的な言い方ですね]
与えられたアプリケーションが稼働する各自のシステムの OS の選択は
性能の数値と独立してはいません。性能は OS を選択する上での幾つかの
基準の内の一つで、通常はわざわざ Linux と他の Unix でない OS を比較
するときには、ほとんど意味のあることではありません。
また、異なる OS で類似の性能の数値は大変異なるか若しくは、殆んどの
場合、製作する事さえまったく不可能です。Linux と 他の Unix の変種
を比較するときは、重要な点は議論の余地がある問題点で:
対する "犠牲者" はいつも BSD の変種である Sun Solaris 又は Sun OS,
NextStep, AIX 若しくは HP/UX で、それらは GPL に準拠してなかったり
多くは Linux の稼働しないプラットフォームで稼働するものです。
Q2.Linux システム用の一つの価値ある数値はありますか ?
A:いいえ、ありがたいことに誰も Lhinuxstone (tm) 測定値
のようなものは出てきていません。そのようなものがあったとしても
Web サーバが個々のグラフィックワークステーションへ高い負荷をかける
ような Linux システムは多くの色々なタスクが動作しています。このよ
うないろいろな状況にある Linux システムについて利点の比喩的表現は
ありません。
Q3.この時、どうやって多様な Linux システムの色々な
性能を幾つかの数字にまとめたら良いでしょう ?
A:理想的な状況を仮定します。現実にしたいと思います。
事実、Washington Area Unix User Group が
を Linux Benchmarking Project のために設定していて、Linux のベンチ
マーク結果用のオンラインデータベースが本当にすぐに持てるようになる
でしょう。
Q4.BogoMips って ?
A:BogoMips はお手元のシステムの性能を表すものではあり
ません。BogoMips Mini-HOWTO を調べてください。
Q5.Linux 用の "最高の" ベンチマークは何ですか ?
A:Linux システムのどの角度の性能を計りたいかによります。
ネットワーク性能 (一様の転送速度の Ethernet), ファイルサーバ (NFS),
ディスク入出力, FPU, 整数, グラフィックス, 3D, プロセッサ-メモリ
帯域幅, CAD 性能, トランザクション時間, SQL 性能, Web サーバ性能,
実時間性能, CD-ROM 性能, 耐震性能 (!), 等などを網羅する Linux 用
のベンチマークスイートは筆者が知る限り今までありません。
Q6.Linux 下で最高速のプロセッサは何ですか ?
A:どの業務で最高速なのでしょう ? 重い数値計算よりの業務
の場合は Alpha が該当する業務向けに設計されているので、高クロックの
Alpha (600 MHz 以上) が他よりは速いでしょう。また一方、速いニュース
サーバがほしい場合は高速なディスクサブシステムを選択し沢山のメモリ
を積んだシステムが同じ費用でプロセッサを変更するよりはより高い性能
を結果として残すでしょう。
Q7.質問を言い換えると、つまり:
汎用的なアプリケーションで最高速のプロセッサは何ですか ?
A:油断のならない質問ですが、とても単純な答があります。:
ありません。いつも汎用的なアプリケーション用に高速な
システムを設計したとしてもプロセッサ依存になります。通常、
ほかの部分は高いクロック速度が高性能のシステムを結果として生じます。
(頭痛も起きますけど)。 古い 100 MHz の Pentium をアップグレード
可能な (通常違いますが) マザーボードから取り出して, 200 MHz 版を
さした時には余分に "ふーん" と感じるでしょう。勿論、8 メガバイト
のメモリしかない元のシステムに、同額の投資で余分に SIMM を買った
方がより賢いと思います。
Q8.そんなにクロック周波数がシステムの性能に影響がありますか?
A:NOP 命令のループを除いたほとんどのタスクでは (新しい
最適化コンパイラは NOP 命令を取り除くけれど) 、(同じプロセッサ
アーキテクチャでは) クロック周波数が増加
すると線形に性能向上します。プロセッサ内蔵の 1 次キャッシュ
(L1 キャッシュ、通常 8 または 16 K) に完全に
はまりこんでしまう、データが高度に局所化していて入出力がとても少ない
ような、十分小さなプロセッサ集中的なプログラム
はクロック周波数の増加と同時に性能向上しますが、殆んどの "本物の"
プログラムはそのようなプログラムよりかなり大きく L1 キャッシュに
入らないほど大きいループを持っていて、(外部の) L2 キャッシュを
ほかのプロセスと共有しています。よって外部の構成要素に依存し少し
性能が向上するかもしれません。したがってプロセッサと同一クロック
周波数で L1 キャッシュは (通常) 動作していますが、ところが L2
キャッシュと
他のサブシステム (例えば DRAM) はより低いクロック周波数で非同期に
動作しています。幾つかのプロセッサは L1, L2 と L3 キャッシュさえ
持っています。
Q9.分かりました。では、最後の質問を次の事象について:
一般的な目的向け Linux の最高のコストパフォーマンスのプロセッサは何で
しょう ?
A:"一般的な目的向け Linux" の定義は簡単なものではありませ
ん。特定のアプリケーション向けなら、与えられた時間で最高のコスト
パフォーマンスは考えられますが、製造会社は新しいプロセッサをかなり
頻繁に発表し、価格を変更するので n MHz で動作するプロセッサ XYZ
という舌足らずの
答が出てきます。しかしながら、プロセッサの価格はシステムを合わせた
全体の価格の中ではささいなものでしょう。従って、実際には、質問は
どうやってシステムのコストパフォーマンスを最大にするか ? ですね。
そして、最低の性能の必要条件と/または考えている構成が最大コスト
に納まることに深く依存していますね。時々、既製のハードウェアでは
最低性能要件に出会うことは無いでしょう。高価な RISC の
システムは選択肢にしかすぎません。そしてボトルネックの殆んどは
プロセッサの性能ではなくディスクの入出力です。自宅で使うには、
全体の性能が安定
した、均質的なシステムをお勧めします。(安定と均質が何をさしているか
思い浮かべてください :-); プロセッサの選択は重要な決定事項ですが、
ハードディスクの型と容量、メモリの量、ビデオカード等を選択するのも
大切です。
Q10.性能において "意味のある" 増分とは何でしょう ?
A:1% 以下のものを重要とは言いません("わずかな"
と記述することにします)。我々、人間は応答時間が 5 % 異なるとき
はっきりと二つのシステムの違いを知覚できます。勿論、いくつかの徹底
したベンチマークは人間ではないですからシステムを比較して性能指標が
65.9 と 66.5 という場合は後者を "明確に高速である" と言います。
Q11.最低の費用で性能においてどのようにして "意味のある"
増分を得られるでしょう ?
A:Linux のソースコードが利用可能なのだから、注意深く
鍵となるサブルーチンのアルゴリズムを再設計すればいくつかの場合に
性能が驚くほど向上するかもしれません。商用プロジェクトと関係する
か C のソースコードを深く探究するのがイヤなら
Linux コンサルタントを呼ぶべきでしょう。
Consultants-HOWTO を参照してください。
付録
- アーキテクチャ(Architecture): 命令セット、レジスタ
セットとプロセッサの一般的な機能の種類。
- ベンチマーク: コンピュータの性能測定に関する
良く文書化された、標準化された手順
- 効率: 特定のアーキテクチャでのクロックサイクル当りの
計算の実行結果の百分率で通常記述します。
- FPU: 浮動小数点ユニット(Floating Point Unit)。
浮動小数点計算専用のハードウェア構成要素。
- GPL (又は GNU/GPL): GNU General Public License。
協調ソフトウェア開発の努力の成果に高い自由度を提供するソフトウェア
ライセンス。GNU/GPL ライセンスは Linux カーネルソースと共に提供され
(COPYING ファイルを参照してください) ています。拡張されて、GNU/GPL
ライセンスの下に置かれている場合はソフトウェアパッケージが GPL に
従っていると呼ばれます。
- 指標 (Index): 相対性能の大きさ。全ての大きさは
指標が 1.0 である参考システムに対して基準に合わせます。
- MFLOPS: Millions of FLoating-point Operations Per
Second の略(メガフロップス)。秒当たりの浮動小数点命令の実行回数の
百万回単位量。浮動小数点計算性能の大きさ。
同様に GFLOPS は ギガ(Giga)-FLOPS, TFLOPS はテラ(Tera)-FLOPS,
KFLOPS はキロ(Kilo)-FLOPS のことです。FLOPS 量を使うときは常に
単精度若しくは倍精度であるか明記すべきです。
- MIPS: Millions of Instructions Per Second の略
(ミップス)。 CPU アーキテクチャの効率の問題点、入出力周りの操作、
OS のオーバヘッド等を無視した計算性能の不正な大きさ。
- 性能: 与えられた計算タスクを実行するシステム
(ハードウェア/ソフトウェアの組み合わせ) に必要な時間。
- 分散: 特定のベンチマークによって提供される情報
またはシステムの特定の性能の見地。例えば、FPU ベンチマークは
Web サーバの性能測定には不適切です。
- 解像度: 与えられたシステム上での特定のベンチマーク
で測定された最小の性能の変動量。
- 価値ある一つの数値: システムの性能の様相を要約するに
十分な一つの数値があれば、それを価値ある一つの数値と呼びます。
コンピュータのある特定のサブシステムの性能を要約することができた場合、
(例えば、FPU 用の価値ある一つの数値) 又は、他とまったく別なコンピ
ュータの機能のテストを組み合わせた結果の要約(例えば、3D グラフィック
性能) がある場合はありますが、システム全般の性能を記述出来るものは
ありません。
- 安定性: メモリリークがない事とマシンを停めてしまわ
ないようなプログラムの品質。とても珍重され、達成するのが難しいです。
性能よりも重要です。
- 分散 与えられたベンチマークの精度の余地の統計量。
著作権表示, 謝辞 と 雑録
何故この文書が作られたか
Greg Hankins による HOWTO の目次の "Writing and submitting a HOWTO"
の 4 章を読んだのが最初です。
筆者は SGML も LaTeX も全く知らなかったけど、SGML-Tools に関する
色々な説明を読んだ後で、自動で文書を生成してくれるパッケージが
あることが分かりました。しかしながらタグを文書の中に手で挿入する
ことは、今は現存しない 8-ビットマイクロプロセッサの 512 バイトの
モニタプログラムをハンドアセンブルしていた頃を思い出させたので、
LyX のソースを持ってきてコンパイルし LinuxDoc モードにして使いま
した。LyX と SGML-Tools の組合わせを強くお勧めします。
[訳注: LyX 日本語版はありませんが、LinuxDoc-SGML 日本語版(パッチ)
があります。SGML-Tools 日本語版はありません。]
著作権表示
The Linux Benchmarking HOWTO is copyright (C) 1997 by AndrDerrick
Balsa.
Linux HOWTO 文書は全部若しくは部分でもどんな物理媒体、電子媒体でも
この著作権表示をそっくり保持するかぎり複写と配布が可能です。
商用再分配を許諾し奨励します; しかしながら著者は商用再配布を
行う時は通知して頂きたく思います。
翻訳、派生的な著作 または幾つかの Linux HOWTO 文書を組織化し集約した
著作の全てはこの文書の著作権表示の保護を受けます。これは HOWTO から
派生的な作業を生ませないものでなく、文書の配布に制限を追加するもの
ではありません。これらの規則の例外は正当な条件で承諾する事であり、
以下に示すアドレスの Linux HOWTO のまとめ役に連絡を取ってください。
手短に言えば、我々は可能な限り多くの経路を通じてこの情報が普及、
促進することを願っています。しかしながら、HOWTO 文書の著作権が
保持され、この HOWTO 文書の再配布計画の通知を頂きたく思います。
質問があるときは、Linux HOWTO まとめ役である Greg Hankins
に連絡を取ってください。電子メール経由で
までお願いします。
この文書の新版
Linux Benchmarking-HOWTO の新版は sunsite.unc.edu とそのミラーサイト
に置かれます。他の書式ではポストスクリプトと dvi 版が other-formats
ディレクトリに置かれています。Linux Benchmarking-HOWTO は
で
書かれた Grail のような Web ブラウザからも利用可能です。
この文書の新版は comp.os.linux.answers に定期的に投稿されます。
フィードバック
提案、修正、追加を欲しています。貢献者を募集していますし感謝していま
す。激論となるのは望んでいません。
筆者はいつでも andrewbalsa@usa.net にいます。
謝辞
色々な貢献と提案をいただきました
Jeremy Chatfield (Xi Graphics 所属), Uwe Mayer, David Niemi, と
Kazuyuki Okamoto に感謝したいです。
また、Linux HOWTO のまとめ役と SGML-tools パッケージの寄付者の一人
である Greg Hankinsと, Linus Torvalds と活発な Linux コミュニティ
にも感謝を表したいです。この HOWTO が恩返しになるように。
放棄声明文
読者の利益は様々でしょう。ベンチマークは物議をかもす題目であり
、大きな時間とエネルギーを消費する活動だと理解して下さい。
商標
Pentium と Windows NT は Intel Corporation と Microsoft Corporation
の商標です。
Cyrix と 6x86 は Cyrix Corporation の商標です。
Linux は実際は Linus Torvalds の登録商標です。:-)