Linux ベンチマーク HOWTO by Andri D. Balsa, andrewbalsa@usa.net v0.15, 21 September 1997 岡本 一幸 Kazuyuki Okamoto v0.12, 17 October 1997 Linux ベンチマーク HOWTO は Linux システムのベンチマークに関する事項と Linux Benchmarking Toolkit (LBT) の構成を検討します。 LBT はベンチマー クスイートと導入から最終報告書を手にいれる迄、数時間で関連する該当する ベンチマーク情報を作成できる報告書の書式を組み合わせたものです。基本的 な考え方は正確さと、無料で自由に利用可能な (GPL に従っている) ソフト ウェアツールを使用した色々な Linux システム構成の性能比較を文書化可能 にすることです。 ______________________________________________________________________ 目次 1. はじめに 1.1 ベンチマークは何故そんなに重要なのか ? 1.1.1 意思決定 1.1.2 Linux の進歩 1.2 無効なベンチマークの検討 2. ベンチマークの手順と結果の解釈 2.1 ベンチマークの選択を理解する 2.1.1 合成ベンチマーク対アプリケーションベンチマーク 2.1.2 ユーザレベル 対 マシンレベル ベンチマーク 2.2 Linux で可能な標準ベンチマーク 2.2.1 カーネルのコンパイル 2.2.2 Linux 固有のベンチマークツール 2.3 その他のリンク情報と参考文献 3. Linux ベンチマーク ツールキット (LBT) 3.1 理論的根拠 3.2 ベンチマークの選択 3.3 テスト存続期間 3.4 コメント 3.4.1 Kernel 2.0.0 コンパイル: 3.4.2 UnixBench version 4.10: 3.4.3 Xengine: 3.4.4 BYTE マガジンの BYTEmark ベンチマーク: 3.5 考えられる改善 3.6 LBT レポートの書式 3.7 ネットワーク性能テスト 3.8 Symmetric Multi Processing (SMP) 対称型マルチプロセッサテスト 4. 例題の実行と結果 5. ベンチマークの落とし穴と警告 5.1 リンゴとオレンジを比べる事 5.2 不完全な情報 5.3 所有者のハードウェア/ソフトウェア 5.4 妥当性 5.5 分散 5.6 不正な統計的/論理的推定 6. FAQ 7. 付録 8. 著作権表示, 謝辞 と 雑録 8.1 何故この文書が作られたか 8.2 著作権表示 8.3 この文書の新版 8.4 フィードバック 8.5 謝辞 8.6 放棄声明文 8.7 商標 ______________________________________________________________________ 1. はじめに "言ってはいけないことは沈黙に置き去りにしなければならない。" Ludwig Wittgenstein (1889-1951), オーストリアの哲学者 ベンチマークとは計算処理の速度を 測定 したもので、色々なハードウェアと ソフトウェアのシステム設定の比較に用いられます。ベンチマークはユーザの 使いやすさや、美的感覚、人間工学的検討や他の主観的な意見には関係があり ません。 ベンチマークは退屈で反復の多い作業で細部に注意を喚起するものです。かな り頻繁にその結果は期待に反するもので、(ベンチマークの手順の殆んど重要 な部分を占める) 解釈の題材になります。 最終的に、ベンチマークは意見や近似値ではなく事実と数値を扱います。 1.1. ベンチマークは何故そんなに重要なのか ? 1.1.1. 意思決定 BogoMips Mini-HOWTO (セクション 8, 第 2 段落) に指摘される理由とは別 に、時折、Linux マシンにかけられる限られた予算と/又は最低限の性能要求 に直面する場合にベンチマークは重要です。言い換えれば、次の質問を対比す ることになります。: o 与えられた予算内で性能はどうしたら最大にできるか ? o 最低性能要求の水準の為の費用を如何に最小にできるか ? o (与えられた予算または与えられた性能要件内で) 最高の性能/費用比をど うしたら得られるか ? ベンチマークを調査、比較、作成しなければなりません。性能要件が無い場 合、通常 (ガレージにあるような古い 386SX-16 マシンに相当する) 残りの部 品で組んだベンチマークの必要のないマシンの費用の最小化と、費用の制限が ない場合の最大性能のマシンについての性能の最大化の作業は実世界にはあり ません。 (皮カバーのかかった電源装置が回りに置いてある Cray マシンは個 人の居間に置くには魅力的ですがこのような事は除きます。) このようなベンチマークは無意味で時間と金の無駄です。例えば 2 つ 3 つの 内から選択しなければならない場合など決定過程の一部としてしか意味があり ません。 コンピュータシステムの可用性、客への対応、信頼性、戦略的理由やその他合 理性のある測定可能な特徴づけ等がありますが、通常、決定過程における他の パラメータは費用です。色々なカーネルのバージョンの性能を比較するとき、 例えば安定性 は 常に 速度より重要です。 1.1.2. Linux の進歩 Linux は常により効率よく、Unix に互換性のある実装に向けて進化している ので、種々のアルゴリズム (ハードディスクのアクセス、タスクスケジュール 等) での効率性と安定性を測定したくなるでしょう。ベンチマークはボトル ネックを発見したり、失敗する条件 (例えば負荷が重い場合) の可能性を発見 するのに役に立つでしょう。 1.2. 無効なベンチマークの検討 残念ながら、ニュースグループやメーリングリストで良く見られる事に: 1. 製造者の評判 (測定不可能で意味がありません) 2. 製造者の市場占有率 (意味がなく不適切です) 3. 不合理な要因 (例えば、迷信とか偏見 : 131313Z というプロセッサを買っ てピンクに塗りました ? とかね) 4. 誇大な宣伝: 筆者が思うに最悪です。個人的には "humhumhum inside" と か "kkkkkws compatible" というロゴにはうんざりしています。 (今では "aaaaaPowered" が流行っているけど、次はなんでしょう ?) こんなキャ ンペーンに巨額の費用を費やすぐらいなら、新しくて速くて (安くて :-) バグのないプロセッサを作った方がよろしいでしょう。誇大な宣伝を止め て、このマザーボードに差してある新しいプロセッサの FPU の浮動小数点 のバグを取るか若しくは再開発するプロセッサと交換するかが良いでしょ う。 5. "お金を払って欲しいものを手にいれる" という意見はごもっともです。冷 静で、現実的な事実 を教えてください。 2. ベンチマークの手順と結果の解釈 幾つかの若干明白な推奨手順があります。: 1. 最初でかつ主要部分はベンチマークの目的を確認しましょう。本当にベン チマークしたいのは何でしょう ? ベンチマークの過程の最後の意思決定や 進化する Linux で何を決定したいのでしょう ? ベンチマークの成果を得 るのにどれくらいの時間と資源をかけられますか ? 2. 標準的なツールを使いましょう。最新で、安定版のカーネル版で、標準的 な最新の gcc と libc で (例えば、Linux Benchmarking Toolkit) のよう な標準的なベンチマークを行いましょう。 3. お手元の (例えば、LBT レポートの書式の) セットアップについて完全な 説明をしましょう。 4. 一つの変更点だけ分離してみてください。あらゆる所で、相対的なベンチ マークは "絶対的な" ベンチマークより有益です。そんなに筆者は強制で きません。 5. 結果を検証してください。出来れば、数回ベンチマークを実行し、結果の 変動を検証してください。説明できない変動があれば無効なベンチマーク 結果という事です。 6. ベンチマークの成果が意味のある情報を含んでいると考えたら、正確かつ 簡潔に Linux コミュニティーで情報を共有しましょう。 7. BogoMips については忘れてください。筆者自身に誓って、いつか BogoMips ループ用の超高速の ASIC を実装します。そのとき我々は何を見 ているか分かるでしょう。 2.1. ベンチマークの選択を理解する 2.1.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 の変更の方が大きいので全然使い 物になりません。もちろん、同じカーネルとドライバの組み合わせで行っても より大きな変動が起こります。 最後に、とても一般的な間違いは色々な合成ベンチマークの平均をとること と、このようにして得た平均がそのシステムに対する実際の性能の良い表現で あると主張することです。結果は二つの非常に異なる理由から使えません。 1. 種々の構成の相対的な強弱を比較する場合は、関連する情報は平均操作で 結局失われてしまいます。 2. 種々の合成テストは実世界の仕事を一緒にこなすような色々なサブシステ ムの性能については何も教えてくれません。 ここでは 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 システム用の標準的なアプリケーションベンチマ ークスイートは利用できるものはありません。 2.1.2. ユーザレベル 対 マシンレベル ベンチマーク マシンレベルベンチマークはハードウェアの性能を直接測定するものです。測 定するものは CPU クロック、DRAM メモリとキャッシュ SRAM のサイクル時 間、バードディスクアクセス時間、潜在時間とトラック間移動時間等々、で す。これらはシステムを買った時やどんな部品でシステムが構築されているか 不思議に思ったときに有効です。しかしの部品を調査するより良い方法は、マ イクロコンピュータのふたを開けてどんな部品があるか数え上げ、何とかして それぞれの部品のデータシートの一覧を得る方が有効です。通常 インター ネット を用います。 他にマシンレベルベンチマークのより良い使用方法はカーネルドライバが正し くハードウェアの仕様通りに構成されているかチェックする事です。これは部 品のデータシートを持っている場合、マシンレベルベンチマークの結果と理論 上の製造者の仕様とを比較できます。 ユーザレベルベンチマークはマイクロコンピュータの特定の角度から見たハー ドウェア/ドライバ/OS/コンパイラ の組み合わせに関係しています。例えば、 ファイル入出力性能とか特定のハードウェア/ドライバ/OS/ コンパイラ/アプ リケーションの性能をみます。つまり色々なマイクロコンピュータ上での特定 の Web サーバパッケージのベンチマークや同じプラットフォーム上での色々 な Web サーバパッケージのベンチマーク等です。 2.2. Linux で可能な標準ベンチマーク 2.2.1. カーネルのコンパイル 個人的な意見ですが、Linux マシンの部品を交換して改善したときだれでも実 行できる簡単なテストはカーネルのコンパイルを起動することです。ハー ド/ソフトウェアの改善前と後の時間を比較してみましょう。その他の条件を 同じにして(つまり例えばカーネルの設定を変えない場合)おかないとコンパイ ル性能の測定は役に立ちません。よって、その次のような言い方が自信をもっ て言えるでしょう。 "A を B に変更したらそのシステムとその条件で Linux のカーネルのコンパ イル時間が x % 向上した"。 それ以上でもなく、それ以下でもありません。 カーネルのコンパイルは Linux の下では普通に経験する作業で、殆んどの関 数が使用されるので (浮動小数点性能を除く) 通常のベンチマークに使用され ます。かなり良い個体テストという性質があります。殆んどの場合、他の Linux ユーザがこのようなテストで同じ結果を再現できないその理由はハー ド/ソフトウェアの構成が色々あるのと、この種のテストが異なるシステム間 の比較に使う "ものさし" が無いことです。(我々全員が標準的カーネルをコ ンパイルする場合を除きます - 後述参照のこと)。 2.2.2. 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 より高速である * 推論: イリノイ大にある全てのマシンは遅い 3. Linux ベンチマーク ツールキット (LBT) Linux 用の基本的なベンチマークツールキットの拡張と改良の為の提案です。 これに価値があるかお手にとって下さい。つまり、作業中ということです。こ れが効果的なテストスイートではないと思ったら気軽に提案を電子メールで筆 者宛てに送付してください。出来るだけ喜んで変更と改良を行うでしょう。と はいっても議論に入る前に、この HOWTO とここで述べた参考文献を読んでく ださい。情報のある批評は歓迎しますが、中身のない批評は歓迎できません。 3.1. 理論的根拠 まさに一般常識ですが: 1. ベンチマークは一日中実行するべきものではありません。比較ベンチマー ク (色々実行します) の場合は、だれもそのシステムの最速の設定を決定 するのに何日も努力したくはありません。理想的には、すべてのベンチマ ーク一式を平均的なマシンと比較するのに 15 分程度かかるでしょう。 2. 明らかな理由で、LBT で使用しているソフトウェアのすべてのソースコー ドは自由にインターネットで利用できなければなりません。多分、GNU/GPL ライセンスに準拠するでしょう。 3. ベンチマークは測定した性能を簡単な数値で提供するべきです。 4. 合成ベンチマークとアプリケーションベンチマークの混合物であるべきで す(もちろん分離した結果と共に)。 5. 合成 ベンチマークのそれぞれは個々のシステムの最大容量を使用するべき です。 6. 合成 ベンチマークの複数の結果を一つの価値ある数値に平均してはいけま せん。合成ベンチマーク全体の考え方を無視できない程の情報の損失を 伴って失敗します。 7. アプリケーションベンチマークは Linux システム上で一般に動作するタス クであるべきです。 8. 結果の分散は同じマシンで同一もしくは同様の負荷状況で継続的に実行し た場合、 1 か 2 % より小さいでしょう。殆んどのベンチマークでは説得 力のある必要条件であることに注意してください。 3.2. ベンチマークの選択 できるだけテストの重複を避けるように 5 つの色々なベンチマークを選択し ました。: 1. Kernel 2.0.0 (標準構成) の gcc によるコンパイル。 2. David C. Niemi による UnixBench ベンチマーク バージョン 4.10。この バージョンの UnixBench は Double Precision Whetstone テストを含んで います。 3. Kazuhiko Shutoh による Xengine 1.0 。 4. Uwe Mayer により変更された BYTE Magazine の BYTEmark ベンチマークの ベータリリース 2 。 3.3. テスト存続期間 1. Kernel 2.0.0 コンパイル: 5 - 30 分、システムの真の性能に依存しま す。 2. UnixBench ベンチマーク バージョン 4.10: 推定 15 分。 3. Xengine: 5 秒。 4. BYTEmark ベンチマーク: 推定: 10 分。 3.4. コメント 3.4.1. Kernel 2.0.0 コンパイル: o 何ものか: LBT 内の唯一のアプリケーションベンチマーク。 o コードは広く入手可能 (例えば 古い Linux CD-ROM に見つかります)。 o ほとんどの Lunuxer は極めてよくカーネルをリコンパイルします。従っ て、これは全体的な性能の意義深い測定です。 o カーネルは巨大で gcc はどっさりメモリを使用します。小さなテストでは L2 キャッシュの大きさを減らしてしまいます。 o たびたびディスクへ入出力を行います。 o テスト手順: パッチなど当ってないきれいな 2.0.0 のソースを入手して標 準のオプションでコンパイルしましょう。エンターキーを繰り返し押して make config を行います。報告する時間はコンパイルにかかった時間で す。例えば make zImage の時間です。make dep, make clean の時間は含 めないで下さい。カーネルの標準のターゲットアーキテクチャは i386 で す。これ以外のアーキテクチャのマシンでコンパイルを行うときは gcc を ターゲットを i386 にしたクロスコンパイルの設定にする必要がありま す。(gcc のクロスコンパイル用の適切なスイッチについてはオンラインマ ニュアルを見てください) o 結果: コンパイル時間を分と秒で計算してください。 (Linux マシンが 30 秒以下のテスト結果を出すまでは秒の端数 (小数点以下) は報告しないで ください。) 3.4.2. UnixBench version 4.10: o 何ものか: Unix 全体の性能を測定する合成ベンチマーク。このテストは FPU, ファイル入出力とカーネルのマルチタスキングを働かせます。David Niemi が倍精度の Whetstone FPU テストを原作の FPU テストの代わりに UnixBench 4.10 の該当部分に実装しています。 o テスト手順: -O2 をつけて make しましょう。 ./Run -1 ./results/報告 ファイル名 としてテストを起動してください。 EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS と SYSTEM CALL OVERHEAD の指標の幾 何平均を計算します。 o 結果: 浮動小数点性能とシステムの指標です。 3.4.3. Xengine: o 何ものか: CPU / ビデオメモリの帯域幅 / X サーバの性能の高レベルのテ ストです。 o 小さな X window 内で 4 サイクルエンジンの動作のシミュレーションを行 なうすてきな、見た目の良い、ユーモアのあるプログラムです。 o LBT の中で一番小さく一番短いテストです。 o テスト手順: xmkmf で当該システム用の makefile を作成して、-O2 をつ けて ( コンパイルの警告を無視して) コンパイルしてください。筆者は筆 者のシステム用にソースを少し修正する必要がありました。: a) XtGetValues 関数を呼んでいる行をコメントにしました。; b) エンジンの 横と縦の大きさを次の 2 行で 200 という固定値を指定しましょう。 o 結果: RPM の値。 o 注意: このテストは X サーバの性能の厳密で、完璧なテストを意味するも のではありません。しかしながら、システムが画面上にカラーの画素を出 力する速度がどれくらい速いかの指標を得ます。知りたい事の最小部分で はないでしょうか ? 3.4.4. BYTE マガジンの BYTEmark ベンチマーク: o 何ものか: CPU 性能の良い測定を提供します。文書から引用します。: "こ れらのベンチマークはシステムの CPU, FPU, とメモリアーキテクチャ の 理論上な上限をあばく事を意味します。ビデオ, ディスク, ネットワーク スループットは測定できません。 (これは異なるベンチマークの領域で す。) 従って、これらのテスト結果をシステムの評価の全部ではなく一部 として使いましょう。" o Whetstone テストが丁度 UnixBench 4.10 に含まれる FPU 性能を表わして いるので、FPU テスト結果は処分しました。 o 整数テストは 2 つのグループに分けましょう。これらはメモリキャッ シュ-CPU 性能とそれらに関係する CPU 整数命令を表しています。 o テスト手順: -O2 をつけて make しましょう。./nbench > myresults.dat 等としてテストを起動してください。そのとき、myresults.dat から STRING SORT, ASSIGNMENT と BITFIELD のテスト指標の幾何学平均を計算 しましょう。これはメモリの指標です。NUMERIC SORT, IDEA, HUFFMAN と FP EMULATION テスト指標の幾何学平均を計算しましょう。これは 整数の 指標 です。 o 結果: メモリの指標と整数の指標の計算は上記で説明しました。 3.5. 考えられる改善 理想的なベンチマークスイートは各サブシステム別の合成ベンチマークと、異 なるアプリケーション用の結果を得るアプリケーションベンチマークを数分で 実行するでしょう。そのベンチマークスイートは自動的に全てのレポートを作 成し、最終的にレポートを Web 上の中央のデータベースに電子メールを送付 し、更新するでしょう。 我々は今までまったく OS 間の移植性について興味を持っていませんでした が、ごく最近 Linux のバージョン (> 2.0.0) と各種プラットフォーム (i386, Alpha, Sparc 等) で少なくとも実行できます。 テストはまたとても不便な "特徴" を持っています。: UnixBench と BYTEmark テストの指標は異なる参考マシンを基にしています。それぞれのテ ストの結果を無効に出来ないことにいらいらします。 次の領域は改良のために必要です。: 1. ネットワークベンチマーク: 単純、簡単で信頼できる方法で短時間 (設定 から実行までで 30 分以下で)のテストネットワーク性能のベンチマークに ついての着想をお持ちの方は、筆者まで連絡下さい。 2. X ベンチマーク: X 用のアクセラレータ関数を働かせるには真の 8, 16, 24 と 32 ビットが必要です。 3. Web サーバベンチマーク: 殆んどの Linux ユーザは商用の PC 機材 + Linux + Apache サーバデーモンで汎用目的の Web サーバを実現していま すが、そのようなマシンでのベンチマークは異なる性能の指標を示しま す。 WebStone 2.01 は良い候補だと思います。 4. ゲーム性能: Doom とか Quake のベンチマークは興味があるでしょう。筆 者は Quake が Pentium 用に手による最適化コードが含まれていると聞い ていて Linux システムの汎用目的のベンチマークには向かないので、 Doom ベンチマークの準備をしています。Doom と Quake の基本的な問題は ソースが利用可能でないことです。 3.6. 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. ______________________________________________________________________ 3.7. ネットワーク性能テスト ネットワーク性能のテストは、最低 2 つのマシン (サーバとクライアント) を必要とするので 2 回設定し、たくさん管理するための数値を設定等しま しょう。TCP/IP イーサネットネットワーク上では、最高の選択は ttcp パッ ケージだと思います。若しくは netperf かもしれません。 3.8. Symmetric Multi Processing (SMP) 対称型マルチプロセッサテスト SMP テストはもう一つの挑戦です。SMP 用に特有に設計したベンチマークは実 用になるマルチプロセッシングの優位性を発揮するアルゴリズムを開発するの が困難なので SMP 自身を調査するのが困難な期間がありました。 Linux はユ ニ(単一)プロセッサ(UP) OS として開始しましたが、Linux カーネルの最新版 (大体 > 2.1.30)では "きめ細かい" マルチプロセッシングを行いますが、今 の段階ではこれ以上の情報はありません。 David Niemi によれば、" ... shell8 が SMP と UP モードの類似したハード ウェア/OS を比較するのに良い仕事をします。" 4. 例題の実行と結果 自宅の自作ペンティアムマシンで 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 プロセッサについて 出来るだけ自分の手で行って結果を報告します ! 5. ベンチマークの落とし穴と警告 この HOWTO を書いた後でベンチマークに関係している "落とし穴" と "警告" という言葉の意味を理解し始めました。 5.1. リンゴとオレンジを比べる事 Apple と PC の事を言いましょうか ? あまりに明らかで詳細について言及し たくない昔の論争です。筆者は Mac 上のワードプロセッサの負荷を平均的な Pentium と比べることが本当のベンチマークになる事を疑っています。Linux と Windows NT 等の起動時間等も同様です。一つの変更を行った Linux マシ ンを比較することを可能な限り努力してください。 5.2. 不完全な情報 一つの例が非常に一般的な間違いを説明します。comp.os.linux.hardware で しばしばみられることは、次のような似た記述があります。: "nnn MHz の XYZ プロセッサを差し込んで linux カーネルをたった i 分でコンパイル出来 ました。" (XYZ, nnn, そして i は必要に応じて読み替えてください) こいつ はいらいらします。なぜなら例えば、メモリの容量、スワップの容量、同時に 動いているタスク、カーネルのバージョン、モジュールの選択、ハードディス クの種類、gcc のバージョン等の情報が無いからです。最低、標準的な情報の 枠組みを提供している LBT レポートの書式を使用することをお勧めします。 5.3. 所有者のハードウェア/ソフトウェア 良く知られているプロセッサ製造会社はかつて特別なカスタマイズした gcc で作成したベンチマークの結果を公表しました。倫理的に考えればこれらの結 果は標準的なバージョンの gcc を使っている Linux コミュニティでは 100% 意味がありません。同じことは所有者のハードウェアにも言えます。ベンチマ ークは既製のハードウェアとフリー (GNU/GPL の考えによる) ソフトウェアに も適応できるからです。 5.4. 妥当性 Linux について話しています、いいですね ? 従って他のオペレーティングシ ステムで作成したベンチマークに関しては忘れましょう (これは上記の "リン ゴとオレンジを比べる" 所の落とし穴の特別な場合になります)。また、Web サーバの性能に言及する場合は、FPU 性能や他の重要でない情報を引き合いに 出す必要はありません。このような場合は、過ぎたるは及ばざるが如しです。 また、ご自分の猫の年齢やご自身の機嫌等にも言及する必要も ありません 。 5.5. 分散 これは結果の再作成に用います。同じシステムで Z ベンチマークを毎回実行 する場合、かなり違った結果 (> 2 %) を得るでしょう。その時、Z ベンチマ ークは十分な精度はでないし、多分再開発する必要もないでしょう。まだ Z ベンチマークを使用したい場合は結果の変動をはっきりと言及するべきで、む しろ結果の平均の百分率とこれらの変動を確率的説明に言及するべきでしょ う。与えられたベンチマークの分散を指摘できない場合とできたとしても、特 別な警戒について議論なしに基本的な仮定として分散は 1 % 以下です。 5.6. 不正な統計的/論理的推定 表面上無害な、明白なベンチマーク結果からベンチマークが失敗だという結論 を出す全ての種類の技があります。これは LBT がこのような判断のためにひ とつの Comments 欄がある理由なのです。その時、それぞれの精密な調査する までデータをソートする良い考え方がいくつかの結論を出す事になります。 6. 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 が Web サイトを 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 を参照してください。 7. 付録 o アーキテクチャ(Architecture): 命令セット、レジスタセットとプロセッ サの一般的な機能の種類。 o ベンチマーク: コンピュータの性能測定に関する良く文書化された、標準 化された手順 o 効率: 特定のアーキテクチャでのクロックサイクル当りの計算の実行結果 の百分率で通常記述します。 o FPU: 浮動小数点ユニット(Floating Point Unit)。浮動小数点計算専用の ハードウェア構成要素。 o GPL (又は GNU/GPL): GNU General Public License。協調ソフトウェア開 発の努力の成果に高い自由度を提供するソフトウェアライセンス。GNU/GPL ライセンスは Linux カーネルソースと共に提供され (COPYING ファイルを 参照してください) ています。拡張されて、GNU/GPL ライセンスの下に置 かれている場合はソフトウェアパッケージが GPL に従っていると呼ばれま す。 o 指標 (Index): 相対性能の大きさ。全ての大きさは指標が 1.0 である参考 システムに対して基準に合わせます。 o MFLOPS: Millions of FLoating-point Operations Per Second の略(メガ フロップス)。秒当たりの浮動小数点命令の実行回数の百万回単位量。浮動 小数点計算性能の大きさ。同様に GFLOPS は ギガ(Giga)-FLOPS, TFLOPS はテラ(Tera)-FLOPS, KFLOPS はキロ(Kilo)-FLOPS のことです。FLOPS 量 を使うときは常に単精度若しくは倍精度であるか明記すべきです。 o MIPS: Millions of Instructions Per Second の略 (ミップス)。 CPU ア ーキテクチャの効率の問題点、入出力周りの操作、 OS のオーバヘッド等 を無視した計算性能の不正な大きさ。 o 性能: 与えられた計算タスクを実行するシステム (ハードウェア/ソフト ウェアの組み合わせ) に必要な時間。 o 分散: 特定のベンチマークによって提供される情報またはシステムの特定 の性能の見地。例えば、FPU ベンチマークは Web サーバの性能測定には不 適切です。 o 解像度: 与えられたシステム上での特定のベンチマークで測定された最小 の性能の変動量。 o 価値ある一つの数値: システムの性能の様相を要約するに十分な一つの数 値があれば、それを価値ある一つの数値と呼びます。コンピュータのある 特定のサブシステムの性能を要約することができた場合、 (例えば、FPU 用の価値ある一つの数値) 又は、他とまったく別なコンピュータの機能の テストを組み合わせた結果の要約(例えば、3D グラフィック性能) がある 場合はありますが、システム全般の性能を記述出来るものはありません。 o 安定性: メモリリークがない事とマシンを停めてしまわないようなプログ ラムの品質。とても珍重され、達成するのが難しいです。性能よりも重要 です。 o 分散 与えられたベンチマークの精度の余地の統計量。 8. 著作権表示, 謝辞 と 雑録 8.1. 何故この文書が作られたか 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 日本語版はありません。] 8.2. 著作権表示 The Linux Benchmarking HOWTO is copyright (C) 1997 by AndrDerrick Balsa. Linux HOWTO 文書は全部若しくは部分でもどんな物理媒体、電子媒体 でもこの著作権表示をそっくり保持するかぎり複写と配布が可能です。商用再 分配を許諾し奨励します; しかしながら著者は商用再配布を行う時は通知して 頂きたく思います。 翻訳、派生的な著作 または幾つかの Linux HOWTO 文書を組織化し集約した著 作の全てはこの文書の著作権表示の保護を受けます。これは HOWTO から派生 的な作業を生ませないものでなく、文書の配布に制限を追加するものではあり ません。これらの規則の例外は正当な条件で承諾する事であり、以下に示すア ドレスの Linux HOWTO のまとめ役に連絡を取ってください。 手短に言えば、我々は可能な限り多くの経路を通じてこの情報が普及、促進す ることを願っています。しかしながら、HOWTO 文書の著作権が保持され、この HOWTO 文書の再配布計画の通知を頂きたく思います。 質問があるときは、Linux HOWTO まとめ役である Greg Hankins に連絡を取っ てください。電子メール経由で gregh@sunsite.unc.edu までお願いします。 8.3. この文書の新版 Linux Benchmarking-HOWTO の新版は sunsite.unc.edu とそのミラーサイトに 置かれます。他の書式ではポストスクリプトと dvi 版が other-formats ディ レクトリに置かれています。Linux Benchmarking-HOWTO は Python で書かれた Grail のような Web ブラウザからも利 用可能です。この文書の新版は comp.os.linux.answers に定期的に投稿され ます。 8.4. フィードバック 提案、修正、追加を欲しています。貢献者を募集していますし感謝していま す。激論となるのは望んでいません。筆者はいつでも andrewbalsa@usa.net にいます。 8.5. 謝辞 色々な貢献と提案をいただきました Jeremy Chatfield (Xi Graphics 所属), Uwe Mayer, David Niemi, と Kazuyuki Okamoto に感謝したいです。 また、Linux HOWTO のまとめ役と SGML-tools パッケージの寄付者の一人であ る Greg Hankinsと, Linus Torvalds と活発な Linux コミュニティにも感謝 を表したいです。この HOWTO が恩返しになるように。 8.6. 放棄声明文 読者の利益は様々でしょう。ベンチマークは物議をかもす題目であり、大きな 時間とエネルギーを消費する活動だと理解して下さい。 8.7. 商標 Pentium と Windows NT は Intel Corporation と Microsoft Corporation の 商標です。 Cyrix と 6x86 は Cyrix Corporation の商標です。 Linux は実際は Linus Torvalds の登録商標です。:-)