<!-- LinuxDoc file was created by LyX 0.10 (C) 1995 1996 by Matthias 
Ettrich -->
<!-- Export filter v0.5 by Pascal Andre                               
 -->

<!doctype linuxdoctr system>

<article>

<!--
<title>Linux Benchmarking HOWTO
 -->
<title>Linux ベンチマーク HOWTO
</title>
<author>by Andri D. Balsa, <url url="mailto:andrewbalsa@usa.net" 
name="andrewbalsa@usa.net ">
<date>v0.15, 21 September 1997
<trans> 岡本　一幸 Kazuyuki Okamoto &lt;ikko-@pacific.rim.or.jp&gt;
<tdate>v0.12, 17 October 1997

<!--
<abstract>The Linux Benchmarking HOWTO discusses the issues 
associated with benchmarking on Linux systems, and specifies the 
components for the Linux Benchmarking Toolkit (LBT). The LBT is a 
combination of a benchmark suite and an associated Report Form that 
enables one to produce relevant benchmarking information in a couple 
of hours, from installation to final report. The basic idea is to 
enable precise, documented performance comparisons of various Linux 
system configurations using freely available (GPLed) software tools.
</abstract>
 -->
<abstract>Linux ベンチマーク HOWTO は Linux システムのベンチマーク
に関する事項と Linux Benchmarking Toolkit (LBT) の構成を検討します。
LBT はベンチマークスイートと導入から最終報告書を手にいれる迄、
数時間で関連する該当するベンチマーク情報を作成できる報告書の
書式を組み合わせたものです。基本的な考え方は正確さと、無料で
自由に利用可能な (GPL に従っている) ソフトウェアツールを使用した
色々な Linux システム構成の性能比較を文書化可能にすることです。
</abstract>

<toc>
<!--
<sect>Introduction 
 -->
<sect>はじめに
<p>

<!--
<em>"What we cannot speak about we must pass over in silence."</em>

<em>Ludwig Wittgenstein (1889-1951), Austrian philosopher </em>
 -->
<em>"言ってはいけないことは沈黙に置き去りにしなければならない。"</em>

<em>Ludwig Wittgenstein (1889-1951), オーストリアの哲学者</em>

<!--
Benchmarking means <bf>measuring</bf> the speed with which a computer 
system will execute a computing task, in a way that will allow 
comparison between different system configurations (hardware and 
software). It <bf>does not</bf> involve user-friendliness, aesthetic 
or ergonomic considerations or any other subjective judgment. 
 -->
ベンチマークとは計算処理の速度を <bf>測定</bf> したもので、色々な
ハードウェアとソフトウェアのシステム設定の比較に用いられます。
ベンチマークは
ユーザの使いやすさや、美的感覚、人間工学的検討や他の主観的な意見
には関係が<bf>ありません</bf>。

<!--
Benchmarking is a tedious, repetitive task, and takes attention to 
details. Very often the results are not what one would expect, and 
subject to interpretation (which actually may be the most important 
part of a benchmarking procedure). 
 -->
ベンチマークは退屈で反復の多い作業で細部に注意を喚起するものです。
かなり頻繁にその結果は期待に反するもので、(ベンチマークの手順の
殆んど重要な部分を占める) 解釈の題材になります。

<!--
Finally, benchmarking deals with facts and figures, not opinion or 
approximation. 
 -->
最終的に、ベンチマークは意見や近似値ではなく事実と数値を扱います。
<!--
<sect1>Why is benchmarking so important ? 
 -->
<sect1>ベンチマークは何故そんなに重要なのか ?
<p>
<!--
<sect2>Decision making
 -->
<sect2>意思決定
<p>

<!--
Apart from the reasons pointed out in the BogoMips Mini-HOWTO 
(section 8, paragraph 2), one occasionally is confronted with a 
limited budget and/or minimum performance requirements while putting 
together a Linux box. In other words, when confronted with the 
following questions: 
<itemize>
<item>How do I maximize performance within a given budget ? 
<item>How do I minimize costs for a required minimum performance 
level ? 
<item>How do I obtain the best performance/cost ratio (within a given 
budget or given performance requirements)? 
</itemize>
 -->
BogoMips Mini-HOWTO (セクション 8, 第 2 段落) に指摘される理由とは
別に、時折、Linux マシンにかけられる限られた予算と/又は最低限の性能
要求に直面する場合にベンチマークは重要です。言い換えれば、次の質問を
対比することになります。:
<itemize>
<item>与えられた予算内で性能はどうしたら最大にできるか ?
<item>最低性能要求の水準の為の費用を如何に最小にできるか ?
<item>(与えられた予算または与えられた性能要件内で) 最高の性能/費用
比をどうしたら得られるか ?
</itemize>

<!--
one will have to examine, compare and/or produce benchmarks. 
Minimizing costs with no performance requirements usually involves 
putting together a machine with leftover parts (that old 386SX-16 box 
lying around in the garage will do fine) and does not require 
benchmarks, and maximizing performance with no cost ceiling is not a 
realistic situation (unless one is willing to put a Cray box in 
her/his living room - the leather-covered power supplies around it 
look nice, don't they ?). 
 -->
ベンチマークを調査、比較、作成しなければなりません。
性能要件が無い場合、通常 (ガレージにあるような古い 386SX-16 マシンに
相当する) 残りの部品で組んだベンチマークの必要のないマシンの費用の
最小化と、費用の制限がない場合の最大性能のマシンについての性能の
最大化の作業は実世界にはありません。
(皮カバーのかかった電源装置が回りに置いてある Cray マシンは
個人の居間に置くには魅力的ですがこのような事は除きます。)

<!--
Benchmarking per se is senseless, a waste of time and money; it is 
only meaningful as part of a decision process, i.e. if one has to 
make a choice between two or more alternatives.
 -->
このようなベンチマークは無意味で時間と金の無駄です。例えば 2 つ 3 つの
内から選択しなければならない場合など決定過程の一部としてしか意味があり
ません。

<!--
Usually another parameter in the decision process is <bf>cost</bf>, 
but it could be availability, service, reliability, strategic 
considerations or any other rational, measurable characteristic of a 
computer system. When comparing the performance of different Linux 
kernel versions, for example, <bf>stability</bf> is <bf>ALWAYS</bf>
more important than speed.
 -->
コンピュータシステムの可用性、客への対応、信頼性、戦略的理由や
その他合理性のある測定可能な特徴づけ等がありますが、
通常、決定過程における他のパラメータは<bf>費用</bf>です。
色々なカーネルのバージョンの性能を比較するとき、例えば
<bf>安定性</bf> は <bf>常に</bf> 速度より重要です。
<!--
<sect2>Linux progress
 -->
<sect2>Linux の進歩
<p>

<!--
Since Linux is always evolving towards a more efficient and
compatible implementation of Unix, we may want to measure the
efficiency and stability of different algorithms (for hard-disk
access, task scheduling, etc). Benchmarks are useful in such cases to
identify bottlenecks and/or possible failure conditions (e.g. under
heavy load).
 -->
Linux は常により効率よく、Unix に互換性のある実装に向けて進化している
ので、種々のアルゴリズム (ハードディスクのアクセス、タスクスケジュー
ル等) での効率性と安定性を測定したくなるでしょう。ベンチマークは
ボトルネックを発見したり、失敗する条件 (例えば負荷が重い場合) の
可能性を発見するのに役に立つでしょう。
<!--
<sect1>Invalid benchmarking considerations
 -->
<sect1>無効なベンチマークの検討
<p>

<!--
Very often read in newsgroups and mailing lists, unfortunately: 
<enum>
<item>Reputation of manufacturer (unmeasurable and meaningless). 
<item>Market share of manufacturer (meaningless and irrelevant). 
<item>Irrational parameters (for example, superstition or prejudice: 
would you buy a processor labeled 131313ZAP and painted pink ?) 
<item>Perceived value (meaningless, unmeasurable and irrational). 
<item>Amount of marketing hype: this one is the worst, I guess. I 
personally am fed up with the "humhumhum inside" or "ddoorss
compatible" logos (now the "aaaaaPowered" has joined the band - what
next ?). IMHO, the billions of dollars (yes, billions) spent on such
campaigns would be better used by research teams on the design of
new, faster, cheaper :-) bug-free processors. No amount of marketing
hype will remove a floating-point bug in the FPU of the brand-new
processor you just plugged in your motherboard, but an exchange
against a redesigned processor will.
<item>"You get what you pay for" opinions are just that: opinions. 
Give me the <bf>cold, hard facts</bf>, please.
</enum>
 -->
残念ながら、ニュースグループやメーリングリストで良く見られる事に:
<enum>
<item>製造者の評判 (測定不可能で意味がありません)
<item>製造者の市場占有率 (意味がなく不適切です)
<item>不合理な要因 (例えば、迷信とか偏見 :
131313Z というプロセッサを買ってピンクに塗りました ? とかね)
<item>誇大な宣伝: 筆者が思うに最悪です。個人的には "humhumhum
inside" とか "kkkkkws compatible" というロゴにはうんざりしています。
(今では "aaaaaPowered" が流行っているけど、次はなんでしょう ?)
こんなキャンペーンに巨額の費用を費やすぐらいなら、新しくて速く
て (安くて :-) バグのないプロセッサを作った方がよろしいでしょう。
誇大な宣伝を止めて、このマザーボードに差してある新しいプロセッサ
の FPU の浮動小数点のバグを取るか若しくは再開発するプロセッサと
交換するかが良いでしょう。
<item>"お金を払って欲しいものを手にいれる" という意見はごもっとも
です。
<bf>冷静で、現実的な事実</bf> を教えてください。
</enum>

<!--
<sect>Benchmarking procedures and interpretation of results
 -->
<sect>ベンチマークの手順と結果の解釈
<p>

<!--
A few semi-obvious recommendations:
<enum>
<item>First and foremost, <bf>identify your benchmarking goals</bf>. 
What is it you are exactly trying to benchmark? In what way will the
benchmarking process help later in your decision making or in
advancing Linux? How much time and resources are you willing to put
into your benchmarking effort?
<item><bf>Use standard tools</bf>. Use a current, stable kernel 
version, standard, current gcc and libc and a standard benchmark
(e.g. the Linux Benchmarking Toolkit).
<item>Give a <bf>complete description</bf> of your setup (e.g. the
LBT Report Form).
 -->
幾つかの若干明白な推奨手順があります。:
<enum>
<item>最初でかつ主要部分は<bf>ベンチマークの目的を確認しましょう</bf>。
本当にベンチマークしたいのは何でしょう ? ベンチマークの過程の最後の
意思決定や進化する Linux で何を決定したいのでしょう ? 
ベンチマークの成果を得るのにどれくらいの時間と資源をかけられますか ?
<item><bf>標準的なツールを使いましょう</bf>。最新で、安定版のカーネ
ル版で、標準的な最新の gcc と libc で (例えば、Linux Benchmarking
Toolkit) のような標準的なベンチマークを行いましょう。
<item>お手元の (例えば、LBT レポートの書式の) セットアップについて
<bf>完全な説明</bf>をしましょう。
<!--
<item>Try to <bf>isolate a single variable</bf>. In all cases,
comparative benchmarking is more informative than "absolute"
benchmarking. <bf>I cannot stress this enough.</bf>
<item><bf>Verify your results</bf>. Run your benchmarks a few times 
and verify the variations in your results, if any. Unexplained 
variations will invalidate your results. 
<item>If you think your benchmarking effort produced meaningful 
information, <bf>share it</bf> with the Linux community in a 
<bf>precise</bf> and <bf>concise</bf> way. 
<item>Please <bf>forget about BogoMips</bf>. I promise myself I shall 
someday implement a very fast ASIC with the BogoMips loop wired in. 
Then we shall see what we shall see ! 
</enum>
 -->
<item><bf>一つの変更点だけ分離</bf>してみてください。あらゆる所で、
相対的なベンチマークは "絶対的な" ベンチマークより有益です。
<bf>そんなに筆者は強制できません</bf>。
<item><bf>結果を検証してください</bf>。出来れば、数回ベンチマークを
実行し、結果の変動を検証してください。説明できない変動があれば無効な
ベンチマーク結果という事です。
<item>ベンチマークの成果が意味のある情報を含んでいると考えたら、
<bf>正確</bf>かつ<bf>簡潔</bf>に Linux コミュニティーで<bf>情報を共有
</bf>しましょう。
<item><bf>BogoMips については忘れて</bf>ください。筆者自身に誓って、
いつか BogoMips ループ用の超高速の ASIC を実装します。そのとき我々は
何を見ているか分かるでしょう。
</enum>

<!--
<sect1>Understanding benchmarking choices 
 -->
<sect1>ベンチマークの選択を理解する
<p>
<!--
<sect2>Synthetic vs. applications benchmarks
 -->
<sect2>合成ベンチマーク対アプリケーションベンチマーク
<p>

<!--
Before spending any amount of time on benchmarking chores, a basic 
choice must be made between "synthetic" benchmarks and "applications" 
benchmarks. 
 -->
ベンチマークを雑用として時間に費やす前に、基本的な選択として "合成"
ベンチマークと "アプリケーション" ベンチマークのどちらかを選択しま
しょう。

<!--
Synthetic benchmarks are specifically designed to measure the 
performance of individual components of a computer system, usually by 
exercising the chosen component to its maximum capacity. An example 
of a well-known synthetic benchmark is the <bf>"Whetstone"</bf>
suite, originally programmed in 1972 by Harold Curnow in FORTRAN and
still in widespread use nowadays. The Whestone suite will measure the
floating-point performance of a CPU.
 -->
合成ベンチマークは特にコンピュータシステムの独立した構成部分の
性能を測定するように設計されています。通常、選択した構成部分の最大
能力を使用します。良く知られた合成ベンチマークは元々は 1972 年に
Harold Curnow が FORTRAN でプログラムされた
<bf>Whetstone</bf> スイートで、それにもかかわらず現在でも
普及しています。Whestone スイートは CPU の浮動小数点性能を測定する
でしょう。

<!--
The main criticism that can be made to synthetic benchmarks is that
they do not represent a computer system's performance in real-life
situations. Take for example Whetstone: the main loop is very short
and will easily fit in the primary cache of a CPU, keeping the FPU
pipeline constantly filled and so exercising the FPU to its maximum
speed. Keeping in mind that it was programmed 25 years ago (its
design dates even earlier than that !), when the concept of
instruction pipeline did not even exist, we must make sure we
interpret its results with care, when it comes to benchmarking modern
RISC microprocessors.
 -->
合成ベンチマークについての主な批判はこのベンチマークがそのコン
ピュータシステムの実際の状況での性能を意味するものでは無いという
事です。Whestone スイートを例にあげるとメインループが短く、CPU
の 1 次キャッシュに簡単にぴったりはめ込まれてしまい、FPU パイプ
ラインを絶えず占有するため、FPU は最高速度で動作します。
25 年前にこのプログラムが作成されたことを考慮するならば、命令の
パイプラインの考え方はその頃には存在していません　(Whestone ス
イートの設計はもっと昔に行われたはずです !)ので、現代の RISC 
マイクロプロセッサのベンチマークに使うときは、この結果を注意して
解釈することを確認しなければなりません。

<!--
Another very important point to note about synthetic benchmarks is 
that, ideally, they should tell us something about a specific aspect
of the system being tested, <bf>independently</bf> of all other
aspects: a synthetic benchmark for Ethernet card I/O throughput
should result in the same or similar figures whether it is run on a
386SX-16 with 4 MBytes of RAM or a Pentium 200 MMX with 64 MBytes of
RAM. Otherwise, the test will be measuring the overall performance of
the CPU/Motherboard/Bus/Ethernet card/Memory subsystem/DMA
combination: not very useful since changing the CPU will cause a
greater impact than changing the Ethernet network card (this of
course assumes we are using the same kernel/driver combination, which
could cause an even greater variation)!
 -->
他の注意すべき合成ベンチマークの非常に重要な点は、理想的には、
テストしたシステムの特定の様相を伝えるものであり、他の様相
とは<bf>独立</bf>しています。イーサネットカードの入出力スループット
は4 M バイトメモリの 386SX-16 で実行しても 64 M バイトメモリの
Pentium 200 MMX で実行しても同じか同様の数値になります。別な方法では、
CPU/マザーボード/バス/イーサネットカード/メモリサブシステム/DMA の
組み合わせ全てにわたって測定するテストです。イーサネットカードの変更
よりも CPU の変更の方が大きいので全然使い物になりません。もちろん、
同じカーネルとドライバの組み合わせで行ってもより大きな変動が起こりま
す。

<!--
Finally, a very common mistake is to average various synthetic 
benchmarks and claim that such an average is a good representation of 
real-life performance for any given system. The resulting figure is
absolutely useless for two very different reasons:
<enum>
<item>If we are comparing the relative strengths/weaknesses of
various configurations, the relevant information is totally lost in
the averaging operation.
<item>The various synthetic tests tell us nothing about the
performance of the various subsystems when put to work together in
real-world tasks.
</enum>
 -->
最後に、とても一般的な間違いは色々な合成ベンチマークの平均をとること
と、このようにして得た平均がそのシステムに対する実際の性能の良い表現
であると主張することです。結果は二つの非常に異なる理由から使えません。
<enum>
<item>種々の構成の相対的な強弱を比較する場合は、関連する情報は
平均操作で結局失われてしまいます。
<item>種々の合成テストは実世界の仕事を一緒にこなすような色々な
サブシステムの性能については何も教えてくれません。
</enum>

<!--
Here is a comment on FPU benchmarks quoted with permission from the 
Cyrix Corp. Web site: 
<quote><em>"A Floating Point Unit (FPU) accelerates software designed 
to use floating point mathematics: typically CAD programs,
spreadsheets, 3D games and design applications. However, today's most 
popular PC applications make use of both floating point and integer 
instructions. As a result, Cyrix chose to emphasize "parallelism" in 
the design of the 6x86 processor to speed up software that intermixes 
these two instruction types. </em>
</quote>
 -->
ここでは Cyrix Corp. の許可を受けて Web サイトを引用して FPU ベンチ
マークに対するコメントとします。:
<quote><em>"浮動小数点ユニット (FPU) は浮動小数点計算を使用するソフト
ウェアをより高性能化します。CAD プログラム、スプレッドシート、
3D ゲームと 3D 設計アプリケーションが代表的なものです。しかしながら、
今日の殆んどの一般的な PC アプリケーションは浮動小数点と整数命令の
両方を使っています。結果的に、Cyrix は 6x86 プロセッサの設計において
これら 2 種類の命令が混在しているソフトウェアを高速化する為に
"並行化" を強調することを選択しました。</em>
</quote>

<!--
<quote><em>The x86 floating point exception model allows integer 
instructions to issue and complete while a floating point instruction 
is executing. In contrast, a second floating point instruction cannot 
begin execution while a previous floating point instruction is 
executing. To remove the performance limitation created by the 
floating point exception model, the 6x86 can speculatively issue up 
to four floating point instructions to the on-chip FPU while 
continuing to issue and execute integer instructions. As an example, 
in a code sequence of two floating point instructions (FLTs) followed 
by six integer instructions (INTs) followed by two FLTs, the 6x86 
processor can issue all ten instructions to the appropriate execution 
units prior to completion of the first FLT. If none of the 
instructions fault (the typical case), execution continues with both 
the integer and floating point units completing instructions in 
parallel. If one of the FLTs faults (the atypical case), the 
speculative execution capability of the 6x86 allows the processor 
state to be restored in such a way that it is compatible with the x86 
floating point exception model.</em>
</quote>
 -->
<quote><em>x86 の浮動小数点例外モデルは浮動小数点命令を実行中に整数
命令を発行し完了することを許しています。2 回目の浮動小数点命令は前の
浮動小数点命令の実行中は実行開始できません。浮動小数点例外モデルに
よって引き起こされた性能限界を取り除くには、6x86 が整数命令の実行中
でも推論的に FPU に内蔵した 4 つの浮動小数点命令を発行できるように
しました。例えば、2 つの浮動小数点命令 (FLT) の次に 6 つの整数命令
(INT)、続いて 2 つの FLT を順番に実行するプログラムの場合は、
6x86 プロセッサは全ての 10 個の命令が、最初の FLT の完了前に適切な
実行ユニットに対して発行できます。実行誤りが無い場合 (典型的な場合)
は整数ユニットと浮動小数点ユニットの両方が命令を並列に完了します。
実行誤り (異常な場合) が一つでもあれば、推論的な 6x86 の実行性能は
このような方法では x86 の浮動小数点例外モデルと変らない所まで低く
なってしまいます。</em>
</quote>

<!--
<quote><em>Examination of benchmark tests reveals that synthetic 
floating point benchmarks use a pure floating point-only code stream 
not found in real-world applications. This type of benchmark does not 
take advantage of the speculative execution capability of the 6x86 
processor. Cyrix believes that non-synthetic benchmarks based on 
real-world applications better reflect the actual performance users 
will achieve. Real-world applications contain intermixed integer and 
floating point instructions and therefore benefit from the 6x86 
speculative execution capability."</em>
</quote>
 -->
<quote><em>ベンチマークテストの調査は、純粋な浮動小数点だけの合成
浮動小数点ベンチマークは実世界のアプリケーションには無いものである
ということを明らかにしました。このタイプのベンチマークは 6x86
プロセッサの実行能力の推測には役に立ちません。Cyrix は非合成な
実世界のアプリケーションを基礎にしたベンチマークの方が実際の優秀な
ユーザの仕事をより反映すると思っています。実世界のアプリケーション
は整数と浮動小数点命令の混在したものなので、従って 6x86 の推測的
実行性能が役立つのです。"</em>
</quote>

<!--
So, the recent trend in benchmarking is to choose common applications 
and use them to test the performance of complete computer systems. 
For example, <bf>SPEC</bf>, the non-profit corporation that designed 
the well-known SPECint and SPECfp synthetic benchmarks, has launched
a project for a new applications benchmark suite. But then again, it
is very unlikely that SPEC benchmarks will ever include any GPLed
code: we have to look elsewhere for tests to include in the LBT.
 -->
実際、最近のベンチマークの傾向は一般のアプリケーションを選択し、
完全なコンピュータシステムの性能をテストするのにアプリケーション
を用います。例えば、<bf>SPEC</bf>です。良く知られた SPECint と
SPECfp の合成ベンチマークスイートを設計した非営利団体
<bf>SPEC</bf> が、新しいアプリケーションベンチマークスイートの
プロジェクトに乗り出しました。しかし又、SPEC ベンチマークが
GPL に従うコードに含まれるのは非常に好ましくありません。
LBT 内に含まれるテストを LBT 以外のほかの場所から探してこなければ
いけなくなるからです。

<!--
Summarizing, synthetic benchmarks are valid as long as you understand 
their purposes and limitations. Applications benchmarks will better 
reflect a computer system's performance, but no standard applications
benchmark suite exists for Linux systems.
 -->
要約すると、合成ベンチマークはそれらの目的と限界を理解すれば役に立ち
ます。アプリケーションベンチマークはコンピュータシステムの性能をより
良く反映するものですが、Linux システム用の標準的なアプリケーション
ベンチマークスイートは利用できるものはありません。

<!--
<sect2>High-level vs. low-level benchmarks
 -->
<sect2>ユーザレベル 対 マシンレベル ベンチマーク
<p>

<!--
Low-level benchmarks will directly measure the performance of the 
hardware: CPU clock, DRAM and cache SRAM cycle times, hard disk 
average access time, latency and track-to-track stepping time, etc...
This can be useful in case you bought a system and are wondering what 
components it was built with, but a better way to get this
information would be to open the microcomputer case, list whatever
part numbers you can find and somehow obtain the data sheet for each
part (usually on the Net).
 -->
マシンレベルベンチマークはハードウェアの性能を直接測定するものです。
測定するものは CPU クロック、DRAM メモリとキャッシュ SRAM のサイクル
時間、バードディスクアクセス時間、潜在時間とトラック間移動時間等々、
です。これらはシステムを買った時やどんな部品でシステムが構築されて
いるか不思議に思ったときに有効です。しかしの部品を調査するより良い
方法は、マイクロコンピュータのふたを開けてどんな部品があるか数え上げ、
何とかしてそれぞれの部品のデータシートの一覧を得る方が有効です。
通常 インターネット を用います。

<!--
Another, better use for low-level benchmarks is to check that a
kernel driver was correctly configured for a specific piece of
hardware: if you have the data sheet for the component, you can
compare the results of the low-level benchmarks to the theoretical,
manufacturer specs.
 -->
他にマシンレベルベンチマークのより良い使用方法はカーネルドライバが
正しくハードウェアの仕様通りに構成されているかチェックする事です。
これは部品のデータシートを持っている場合、マシンレベルベンチマーク
の結果と理論上の製造者の仕様とを比較できます。

<!--
High-level benchmarks are more concerned with the performance of the 
hardware/driver/OS/compiler combination for a specific aspect of a
microcomputer system, for example file I/O performance, or even for a 
specific hardware/driver/OS/compiler/application performance, e.g.
benchmarking a specific Web server package on different microcomputer
systems, or different Web server packages on the same platform.
 -->
ユーザレベルベンチマークはマイクロコンピュータの特定の角度から見た
ハードウェア/ドライバ/OS/コンパイラ の組み合わせに関係しています。
例えば、ファイル入出力性能とか特定のハードウェア/ドライバ/OS/
コンパイラ/アプリケーションの性能をみます。つまり色々なマイクロ
コンピュータ上での特定の Web サーバパッケージのベンチマークや同じ
プラットフォーム上での色々な Web サーバパッケージのベンチマーク
等です。

<!--
<sect1>Standard benchmarks available for Linux 
 -->
<sect1>Linux で可能な標準ベンチマーク
<p>
<!--
<sect2>Kernel Compilation
 -->
<sect2>カーネルのコンパイル
<p>

<!--
IMHO a simple test that anyone can do while upgrading any component 
in his/her Linux box is to launch a kernel compile before and after 
the hard/software upgrade and compare compilation times. If all other 
conditions are kept equal (i.e. if you don't change the kernel
configuration, for example) then the test is valid as a measure of
compilation performance and one can be confident to say that: 

"Changing A to B led to an improvement of x &percnt; in the compile
time of the Linux kernel under such and such conditions".

No more, no less ! 
 -->
個人的な意見ですが、Linux マシンの部品を交換して改善したとき
だれでも実行できる簡単なテストはカーネルのコンパイルを起動する
ことです。ハード/ソフトウェアの改善前と後の時間を比較してみましょ
う。その他の条件を同じにして(つまり例えばカーネルの設定を変えない
場合)おかないとコンパイル性能の測定は役に
立ちません。よって、その次のような言い方が自信をもって言えるで
しょう。

"A を B に変更したらそのシステムとその条件で Linux
のカーネルのコンパイル時間が x &percnt; 向上した"。

それ以上でもなく、それ以下でもありません。

<!--
Since kernel compilation is a very usual task under Linux, and since 
it exercises most functions that get exercised by the usual
benchmarks (except floating-point performance), it constitutes a
rather good <bf>individual</bf> test. In most cases, however, results
from such a test cannot be reproduced by other Linux users because of
variations in hard/software configurations and so this kind of test
cannot be used as a "yardstick" to compare dissimilar systems (unless
we all agree on a standard kernel to compile and a standard
benchmarking procedure - see below).
 -->
カーネルのコンパイルは Linux の下では普通に経験する作業で、殆んどの
関数が使用されるので (浮動小数点性能を除く) 通常のベンチマークに使用
されます。かなり良い<bf>個体</bf>テストという性質があります。殆んどの
場合、他の Linux ユーザがこのようなテストで同じ結果を再現できない
その理由はハード/ソフトウェアの構成が色々あるのと、この種のテストが
異なるシステム間の比較に使う "ものさし" が無いことです。(我々全員
が標準的カーネルをコンパイルする場合を除きます - 後述参照のこと)。

<!--
<sect2>Linux-specific benchmarking tools
 -->
<sect2>Linux 固有のベンチマークツール
<p>

<!--
There are no Linux-specific benchmarking tools yet. There are,
however, many Unix benchmarking tools, for example, an improved,
updated version of the Byte Unix Benchmarks put together by David C.
Niemi. It is called UnixBench 4.10 to avoid confusion with earlier
versions. Here is what David wrote about his mods:
<quote><em>"The original and slightly modified BYTE Unix benchmarks 
are broken in quite a number of ways which make them an unusually 
unreliable indicator of system performance. I intentionally made my 
"index" values look a lot different to avoid confusion with the old 
benchmarks."</em>
</quote>
 -->
Linux 固有のベンチマークツールは未だありません。しかしながら、多く
の Unix ベンチマークツールがあります。例えば、
David C. Niemi によって改良され、更新されている Byte Unix Benchmarks
も 一緒に置いてあります。これは以前のバージョンと混乱しないように
UnixBench 4.10 と呼ばれています。ここに David が行った変更点につい
て書いています。:
<quote><em>"原作と若干変更した BYTE Unix ベンチマーク は
まったく当てにならないシステム性能の指標を示す数多くの
ふるまいで止まってしまいます。故意に "指標" の値を古いベンチマーク
の混乱を避けるようにかなり異なったものにしています。"</em>
</quote>

<!--
The Byte Linux Benchmarks David refers to are a slightly modified
version of the Byte Unix Benchmarks dating back from May 1991 (Linux
mods by Jon Tombs, original authors Ben Smith, Rick Grehan and Tom
Yager).

There is a central <htmlurl
url="http://www.silkroad.com/bass/linux/bm.html " name="Web site
">for the Byte Linux Benchmarks, but I recommend you start using the
new UnixBench benchmarks. If you have any questions on Unixbench I
suggest you contact David through a mailing list he has setup for
discussion of benchmarking on Linux and other OS's. Join with
"subscribe bench" sent in the body of a message to <url
url="mailto:majordomo@wauug.erols.com"
name="majordomo@wauug.erols.com">.
 -->
Byte Linux Benchmarks は David が 1991 年 5 月 にさかのぼった 
Byte Unix Benchmarks を少々変更したもの (Linux 用の変更は Jon Tombs
が行い、原著者は Ben Smith, Rick Grehan と Tom Yager) です。

Byte Linux Benchmarks 用は中央に <htmlurl
url="http://www.silkroad.com/bass/linux/bm.html " name="Web サイト
"> がありますが、新しい UnixBench ベンチマークを使用して開始する
ことをお勧めします。Unixbench について質問がある場合は
Linux と その他の OS についてのベンチマークに関する検討を行う
ように設定したメーリングリストを通じて David に連絡することを
提案します。"subscribe bench" というメッセージの本文を
<url url="mailto:majordomo@wauug.erols.com"
name="majordomo@wauug.erols.com"> に送付して参加して下さい。

<!--
Also recently, <url url="mailto:mayer@math.vanderbilt.edu" name="Uwe
F. Mayer">ported the BYTE Bytemark suite to Linux. This is a modern
suite carefully put together by Rick Grehan at BYTE Magazine to test
the CPU, FPU and memory system performance of modern microcomputer
systems (these are strictly processor-performance oriented
benchmarks, no I/O or system-wide performance measurement is taken
into account).
 -->
また最近、<url url="mailto:mayer@math.vanderbilt.edu"
name="Uwe F. Mayer"> が BYTE Bytemark スイートを Linux に移植しまし
た。これは最新のスイートで Rick Greha により BYTE Magazine がテスト
した最新のマイクロコンピュータシステムの CPU, FPU と メモリシステム
の性能と一緒に苦心して置いてあります。(厳密に言えばこれらの
ベンチマークはマイクロプロセッサ性能よりのベンチマークで、入出力とか
システム性能とかは勘定に入っていません。)

<!--
Uwe has also put together a <htmlurl 
url="http://www.math.vanderbilt.edu/~mayer/linux/bmark.html"
name="Web site ">with a database of test results for his version of
the Linux BYTEmark benchmarks.
 -->
Uwe はまた <htmlurl
url="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html"
name=" Web サイト"> に Linux BYTEmark ベンチマークの
彼のバージョンでのテスト結果のデータベースがあります。

<!--
To test the relative speed of X servers and graphics cards, the
xbench-0.2 suite by Claus Gittinger is available from
sunsite.unc.edu, ftp.x.org and other sites. It is relatively old and
IMHO does not correctly reflect the performance of modern accelerated
X servers.
 -->
X サーバとグラフィックカードの相対的な性能をテストするには、
Claus Gittinger による xbench-0.2 スイートが sunsite.unc.edu,
ftp.x.org と その他のサイトから利用可能です。どちらかといえば古く
個人的には最近の加速化された X サーバの性能を正しく反映していない
と思います。
<!--
Quoting Jeremy Chatfield from Xi Graphics:

"<em>Current benchmarks have many weaknesses. For example, they all
fail to show "user-responsiveness", the ratio of how fast the screen
responds to user changes at the mouse and keyboard. Single figure
benchmarks don't help people who primarily use pre-computed graphics
separate their needs from those who primarily use text, or who rely
on the X Server to generate the image from graphics primitives. Most
of what the current benchmarks show is the motherboard
RAM-&gt;host-CPU-&gt;PCI chipset-&gt;graphics board bandwidth. That
*is* a single figure number, but doesn't reflect what an accelerated
X Server does.</em>"

Xfree86.org refuses (wisely) to carry, support or recommend any X
benchmarks.
 -->
Xi Graphics の Jeremy Chatfield の意見を引用します。:

"<em> 最近のベンチマークは多くの弱点があります。例えば、"ユーザ
応答性" つまり、ユーザがマウスやキーボードの変更に対する画面の応答
速度がどれくらい速いのかという事を示すことができません。
一つの代表的なベンチマークはテキストを良く使う人の需要とか、
X サーバ上でグラフィックスプリミティブからイメージを作成する人とは
別に予め計算されたグラフィックを良く使う人以外には助けにはなりませ
ん。ほとんどの現在のベンチマークはマザーボードの
メモリ-&gt;ホスト-CPU-&gt;PCI チップセット-&gt; グラフィックボード
の帯域幅を表示するものです。これは一つの数値 *です* が、
高速化された X サーバを反映するものではありません。</em>"

Xfree86.org は (賢明にも) 如何なるベンチマークも保持および推奨も
辞退しています。

<!--
The <htmlurl url="http://www.goof.com/xbench/" 
name="XFree86-benchmarks Survey ">is a Web site with a database of 
xbench results.
 -->
<htmlurl url="http://www.goof.com/xbench/"    
name="XFree86-ベンチマーク調査">は xbench の結果のデータベースを
置いている Web サイトです。

<!--
FOR pure disk I/O throughput, the hdparm program (included with most 
distributions, otherwise available from sunsite.unc.edu) will measure 
transfer rates if called with the -t and -T switches. This is a
typical low-level benchmark.
 -->
純粋なディスク入出力のスループットについては hdparm プログラム
(殆んどの配布物に含まれていますが、sunsite.unc.edu からも
入手可能です) は -t と -T オプションをつけて実行すると
転送速度を測定できます。これは典型的なマシンレベルベンチマークです。

<!--
There are many other tools freely available on the Internet to test 
various performance aspects of your Linux box. The Linux Benchmarking
Project <htmlurl url="http://wauug.erols.com/bench " name=" Web site
">as links to most of them. This site was setup by the <url
url="http://wauug.erols.com" name="Washington Area Unix Users Group
">with the specific purpose of being the central repository for Linux
benchmarking data on the Net. Note however that it is still very much
work-in-progress.
 -->
他に色々な角度から Linux マシンの性能をテストするフリーなツールが
インターネットで入手可能です。Linux ベンチマークプロジェクト
<htmlurl url="http://wauug.erols.com/bench " name=" Web サイト ">
にほとんど全てのリンクがあります。このサイトは <url
url="http://wauug.erols.com" name="Washington Area Unix Users Group
"> がインタネット上で Linux 用の中央貯蔵所として特定用途に設定して
います。しかしながらまだまだ作業中です。

<!--
<sect1>Other links and references
 -->
<sect1>その他のリンク情報と参考文献
<p>

<!--
The <htmlurl
url="http://sacam.oren.ortn.edu/~dave/benchmark-faq.html"
name="comp.benchmarks FAQ">by Dave Sill is the standard reference for
benchmarking. It is not Linux specific, but recommended reading for 
anybody serious about benchmarking. It is available from a number of 
FTP and web sites and lists <bf>46 different benchmarks</bf>, with
links to FTP or Web sites that carry them. Not all benchmarks listed
are freely available, some are even quite expensive (SPEC for
example), few are GPLed.
 -->
Dave Sill による <htmlurl
url="http://sacam.oren.ortn.edu/~dave/benchmark-faq.html"
name="comp.benchmarks FAQ"> はベンチマークについての
標準的な参考文献です。Linux 特有ではありませんが、ベンチマークに
ついてまじめに取り組むすべての人に読むことをお勧めします。
幾つかの FTP や  Web サイトと <bf>46 の種々のベンチマーク</bf>
の一覧がそれぞれの保持先のリンク情報と一緒に含まれています。
全てのベンチマークは無料で利用可能でないです。幾つかはかなり高価
(例えば SPEC への参加は有料) で、幾つかは GPL に準拠しています。

<!--
I can't go through each one of the benchmarks mentionned in the
comp.benchmarks FAQ, but there is at least one low-level suite which
I would like to comment on: the <htmlurl 
url="http://reality.sgi.com/lm/lmbench/lmbench.html" name=" lmbench 
suite">, by Larry McVoy. Quoting David C. Niemi:
<quote><em>"Linus and David Miller use this a lot because it does 
some useful low-level measurements and can also measure network 
throughput and latency if you have 2 boxes to test with. But it does 
not attempt to come up with anything like an overall "figure of 
merit"..."</em>
</quote>
 -->
筆者は comp.benchmarks FAQ が言及しているベンチマークのそれぞれ
の調査は出来ませんが、筆者が 批評したい Larry McVoy による
<htmlurl
url="http://reality.sgi.com/lm/lmbench/lmbench.html" name=" lmbench
スイート">
に最低 1 つのマシンレベルスイートがあります。David C. Niemi の言葉
を引用します。:
<quote><em>"Linus と David Miller は幾つかの有用なマシンレベルの測定
とネットワークスループットの測定と 2 つのマシンでテストしたときの
ネットワーク潜伏時間の測定に使っています。しかし、全てが "価値ある
数字" ようにはならないと思います。"</em>
</quote>

<!--
A rather complete <htmlurl url="ftp://ftp.nosc.mil/pub/aburto" 
name="FTP site ">for <bf>freely</bf> available benchmarks was put 
together by Alfred Aburto. The Whetstone suite used in the LBT can be 
found at this site.
 -->
Alfred Aburto によるかなりまとまっていて <bf>無料で</bf> 利用できる
<htmlurl url="ftp://ftp.nosc.mil/pub/aburto"
name="FTP サイト"> があります。LBT に使用していた Whetstone
スイートがこのサイトにあります。

<!--
There is a <bf>long, multipart FAQ by Eugene Miya</bf> that gets
posted regularly to comp.benchmarks; it is very humorously written,
nice reading for a rainy day. I can't resist the following quote:
<quote><bf></bf><bf><em>BenchMARKETing</em></bf><em>: The Art of
Selling Inferior Goods</em>
</quote>
 -->
comp.benchmarks に定期的に投稿されている <bf>Eugene Miya による
長編の複数編にわたる FAQ</bf> があります。これは大変面白く、
雨の日に読むのに良いでしょう。次の引用をせずにはいられません:
<quote><bf></bf><bf><em>ベンチまーけてぃんぐ</em></bf><em>:
The Art of Selling Inferior Goods
インテリア商品の営業の技巧 より
</em>
</quote>

<!--
<em>John L. Larson CSRD, University of Illinois at
Urbana-Champaign</em>
 -->
<em>John L. Larson CSRD, University of Illinois at
Urbana-Champaign</em>
<em>...</em>

<!--
<bf></bf><bf><em>Technique 8 - Keep nothing constant</em></bf>
 -->
<bf></bf><bf><em>技法 8 - 一定に保たないこと</em></bf>

<!--
<em>* use A to compute matrix multiplication using an assembly
language library routine</em>

<em>* use B to compute recurrences in FORTRAN</em>

<em>* measure the performance</em>

<em>* Conclusion: A is faster than B</em>

<em>* Corollary: Apples and oranges are both fruits</em>
 -->
<em>* アセンブラのライブラリルーチンを使用してマトリックス乗算を
行う A を使用する</em>

<em>* FORTRAN を流用して計算する B を使用する</em>

<em>* 性能測定をする</em>

<em>* 結論: A が B より高速である</em>

<em>* 推論: 林檎とオレンジは両方とも果実である</em>

<!--
<bf></bf><bf><em>Technique 9 - Compare what A will be with what B is
now</em></bf>

<em>* announce the availability of A in 3 years</em>

<em>* run benchmarks on B</em>

<em>* compare execution speeds</em>

<em>* Conclusion: A is faster than B</em>

<em>* Corollary: All of tomorrow's problems were solved yesterday</em>
 -->
<bf></bf><bf><em>技法 9 - A で得たことと最新の B で得たことを比較する
</em></bf>

<em>* A が 3 年間利用できることが知られている</em>

<em>* B をベンチマークする</em>

<em>* 実行速度を比較する</em>

<em>* 結論: A が B より高速である</em>

<em>* 推論: 明日の問題は昨日解決している</em>
<!--
<bf></bf><bf><em>Technique 10 - Compare A with B's
predecessor</em></bf>

<em>* run benchmarks on A</em>

<em>* recall performance tables from benchmark articles on the Illiac
I</em>

<em>* compare the performance</em>

<em>* Conclusion: A is faster than the HAL-9000</em>

<em>* Corollary: All machines at the University of Illinois are
slow</em>
</title>
 -->
<bf></bf><bf><em>技法 10 - A と B の先輩を比較する
</em></bf>

<em>* A をベンチマークする</em>

<em>* Illiac I でのベンチマークの記事から性能表を思い出す
</em>

<em>* 性能を比較する</em>


<em>* 結論: A は HAL-9000 より高速である</em>

<em>* 推論: イリノイ大にある全てのマシンは遅い</em>

<!--
<sect>The Linux Benchmarking Toolkit (LBT)
 -->
<sect>Linux ベンチマーク ツールキット (LBT)
<p>

<!--
This is a proposal for a basic benchmarking toolkit for Linux, to be
expanded and improved. Take it for what it's worth, i.e. as
work-in-progress. If you don't think it is a valid test suite, feel
free to email me your suggestions and I will gladly make the changes
and improve it if I can. Before getting into an argument, however,
read this HOWTO and the above-mentionned references: informed
criticism is welcomed, empty criticism is not.
 -->
Linux 用の基本的なベンチマークツールキットの拡張と改良の為の提案
です。これに価値があるかお手にとって下さい。つまり、作業中という
ことです。これが効果的なテストスイートではないと思ったら
気軽に提案を電子メールで筆者宛てに送付してください。出来るだけ
喜んで変更と改良を行うでしょう。とはいっても議論に入る前に、この
HOWTO とここで述べた参考文献を読んでください。情報のある批評は
歓迎しますが、中身のない批評は歓迎できません。

<!--
<sect1>Rationale
 -->
<sect1>理論的根拠
<p>

<!--
This is just common sense:
<enum>
<item>It should not take a whole day to run. When it comes to 
comparative benchmarking (various runs), nobody wants to spend days 
trying to figure out the fastest setup for a given system. Ideally, 
the entire benchmark set should take about 15 minutes to complete on 
an average machine.
<item>All source code for the software used in the LBT must be freely
available on the Net, preferably under the GNU/GPL license.
<item>Benchmarks should provide simple figures reflecting the 
measured performance. 
<item>There should be a mix of synthetic benchmarks and application 
benchmarks (with separate results, of course).
<item>Each <bf>synthetic</bf> benchmarks should exercise a particular 
subsystem to its maximum capacity. 
<item>Results of <bf>synthetic</bf> benchmarks should <bf>not</bf> be 
averaged into a single figure of merit (that defeats the whole idea 
behind synthetic benchmarks, with considerable loss of information). 
<item>Applications benchmarks should consist of commonly executed 
tasks on Linux systems. 
<item>Variance in results should be kept to &lt; 1 or 2 &percnt; for
successive runs on the same machine with identical or similar load
conditions. Note that this is a very stringent requirement on most
benchmarks.
</enum>
 -->
まさに一般常識ですが:
<enum>
<item>ベンチマークは一日中実行するべきものではありません。比較ベンチ
マーク (色々実行します) の場合は、だれもそのシステムの最速の設定を
決定するのに何日も努力したくはありません。理想的には、すべての
ベンチマーク一式を平均的なマシンと比較するのに 15 分程度かかるで
しょう。
<item>明らかな理由で、LBT で使用しているソフトウェアのすべての
ソースコードは自由にインターネットで利用できなければなりません。
多分、GNU/GPL ライセンスに準拠するでしょう。
<item>ベンチマークは測定した性能を簡単な数値で提供するべきです。
<item>合成ベンチマークとアプリケーションベンチマークの混合物
であるべきです(もちろん分離した結果と共に)。
<item><bf>合成</bf> ベンチマークのそれぞれは個々のシステムの
最大容量を使用するべきです。
<item><bf>合成</bf> ベンチマークの複数の結果を一つの価値ある数値
に平均しては<bf>いけません</bf>。合成ベンチマーク全体の考え方を
無視できない程の情報の損失を伴って失敗します。
<item>アプリケーションベンチマークは Linux システム上で一般に動作
するタスクであるべきです。
<item>結果の分散は同じマシンで同一もしくは同様の負荷状況で継続的
に実行した場合、 1 か 2 &percnt; より小さいでしょう。殆んどの
ベンチマークでは説得力のある必要条件であることに注意してください。
</enum>

<!--
<sect1>Benchmark selection
 -->
<sect1>ベンチマークの選択
<p>

<!--
I have selected four different benchmarks, trying as much as possible
to avoid overlap in the tests:
<enum>
<item>Kernel 2.0.0 (default configuration) compilation using gcc. 
<item>UnixBench benchmarks version 4.10 by David C. Niemi. This
version of UnixBench includes the Double Precision Whetstone test.
<item>Xengine 1.0 by Kazuhiko Shutoh.
<item>BYTE Magazine's BYTEmark benchmarks beta release 2 as modified
by Uwe Mayer.
</enum>
 -->
できるだけテストの重複を避けるように 5 つの色々なベンチマーク
を選択しました。:
<enum>
<item>Kernel 2.0.0 (標準構成) の gcc によるコンパイル。
<item>David C. Niemi による UnixBench ベンチマーク バージョン 4.10。
このバージョンの UnixBench は Double Precision Whetstone テストを
含んでいます。
<item>Kazuhiko Shutoh による Xengine 1.0 。
<item>Uwe Mayer により変更された BYTE Magazine の BYTEmark ベンチ
マークのベータリリース 2 。
</enum>

<!--
<sect1>Test duration
 -->
<sect1>テスト存続期間
<p>
<!--
<enum>
<item>Kernel 2.0.0 compilation: 5 - 30 minutes, depending on the 
<bf>real</bf> performance of your system. 
<item>UnixBench benchmarks version 4.10: approx. 15 minutes.
<item>Xengine: 5 seconds.
<item>BYTEmark benchmarks: approx. 10 minutes.
</enum>
 -->
<enum>
<item>Kernel 2.0.0 コンパイル: 5 - 30 分、システムの<bf>真の</bf>
性能に依存します。
<item>UnixBench ベンチマーク バージョン 4.10: 推定 15 分。
<item>Xengine: 5 秒。
<item>BYTEmark ベンチマーク: 推定: 10 分。
</enum>

<!--
<sect1>Comments
 -->
<sect1>コメント
<p>
<!--
<sect2>Kernel 2.0.0 compilation: 
 -->
<sect2>Kernel 2.0.0 コンパイル:
<p>
<!--
<itemize>
<item><bf>What:</bf> it is the only application benchmark in the LBT. 
<item>The code is widely available (i.e. I finally found some use for 
my old Linux CD-ROMs). 
<item>Most linuxers recompile the kernel quite often, so it is a 
significant measure of overall performance. 
<item>The kernel is large and gcc uses a large chunk of memory: 
attenuates L2 cache size bias with small tests. 
<item>It does frequent I/O to disk. 
<item>Test procedure: get a pristine 2.0.0 source, compile with 
default options (make config, press Enter repeatedly). The reported 
time should be the time spent on compilation i.e. after you type
<tt>make zImage</tt>, <bf>not</bf> including the <tt>make dep</tt>,
<tt>make clean</tt> steps. Note that the default target architecture
for the kernel is the i386, so if compiled on another architecture,
gcc too should be set to cross-compile, with i386 as the target
architecture (see the man page for gcc for the proper switches for
cross-compilation; I can't provide more info on this since I have
never used the cross-compilation features of gcc).
<item><bf>Results: </bf>compilation time in minutes and seconds
(please don't report fractions of seconds, unless your Linux box can
run this test in less than 30 seconds).
</itemize>
 -->
<itemize>
<item><bf>何ものか:</bf> LBT 内の唯一のアプリケーションベンチマーク。
<item>コードは広く入手可能 (例えば 古い Linux CD-ROM に見つかります)。
<item>ほとんどの Lunuxer は極めてよくカーネルをリコンパイルします。
従って、これは全体的な性能の意義深い測定です。
<item>カーネルは巨大で gcc はどっさりメモリを使用します。小さなテスト
では L2 キャッシュの大きさを減らしてしまいます。
<item>たびたびディスクへ入出力を行います。
<item>テスト手順: パッチなど当ってないきれいな 2.0.0 のソースを入手し
て標準のオプションでコンパイルしましょう。エンターキーを繰り返し押し
て make config を行います。報告する時間はコンパイルにかかった時間で
す。例えば <tt>make zImage</tt> の時間です。<tt>make dep</tt>,
<tt>make clean</tt> の
時間は含め<bf>ない</bf>で下さい。カーネルの標準のターゲットアーキテ
クチャは i386 です。これ以外のアーキテクチャのマシンでコンパイルを
行うときは gcc をターゲットを i386 にしたクロスコンパイルの設定に
する必要があります。(gcc のクロスコンパイル用の適切なスイッチに
ついてはオンラインマニュアルを見てください)
<item><bf>結果: </bf>コンパイル時間を分と秒で計算してください。
(Linux マシンが 30 秒以下のテスト結果を出すまでは秒の端数 (小数点
以下) は報告しないでください。)
</itemize>

<sect2>UnixBench version 4.10:
<p>
<itemize>
<!--
<item><bf>What:</bf> a synthetic benchmark that measures overall Unix
performance. This test will exercise the FPU, file I/O and kernel
multitasking performance. Note that David Niemi has implemented the
Double precision Whetstone FPU test as part of UnixBench 4.10,
instead of the original FPU tests.
<item>I am not yet taking into account the integer arithmetic test
results, keeping only the floating-point and system-related test
results.
<item>Test procedure: make with -O2. Execute with<tt> ./Run -1</tt>
(run each test once). You will find the results in the
./results/report file. Calculate the geometric mean of the EXECL
THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT
SWITCHING, PROCESS CREATION, SHELL SCRIPTS and SYSTEM CALL OVERHEAD
indexes.
<item><bf>Results:</bf> floating-point performance and system indexes.
 -->
<item><bf>何ものか:</bf> Unix 全体の性能を測定する合成ベンチマーク。
このテストは FPU, ファイル入出力とカーネルのマルチタスキングを働かせ
ます。David Niemi が倍精度の Whetstone FPU テストを原作の FPU テスト
の代わりに UnixBench 4.10 の該当部分に実装しています。
<item>テスト手順: -O2 をつけて make しましょう
。<tt> ./Run -1</tt> ./results/報告ファイル名 としてテストを起動して
ください。
EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT,
PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS と
SYSTEM CALL OVERHEAD の指標の幾何平均を計算します。
<item><bf>結果:</bf> 浮動小数点性能とシステムの指標です。
</itemize>
<sect2>Xengine:
<p>
<itemize>
<!--
<item><bf>What:</bf> a high-level test that measures CPU/Video memory
bandwidth/X server performance.
<item>This is a neat, good-looking, humorous program that simulates a
4-cycle engine internal motion in a small X window.
<item>Shortest, smallest test of the LBT.
<item>Test procedure: generate a makefile for your system with xmkmf;
compile with -O2 (ignore the compiler warnings). I had to edit the
source slightly to make it run on my system: a) I commented out the
line with the XtGetValues function call; b) modified the 2 following
lines that set the width and height of the engine widget, so that
these have a fixed value of 200.
<item><bf>Results:</bf> an RPM figure.
<item>Note: this test is not meant as a strict, complete test for X
server performance. However, it gives an indication of how fast a
system will push color pixels on a screen. Isn't that at least part
of what we want to know ?
 -->
<item><bf>何ものか:</bf> CPU / ビデオメモリの帯域幅 / X サーバの性能
の高レベルのテストです。
<item>小さな X window 内で 4 サイクルエンジンの動作のシミュレーショ
ンを行なうすてきな、見た目の良い、ユーモアのあるプログラムです。
<item>LBT の中で一番小さく一番短いテストです。
<item>テスト手順: xmkmf で当該システム用の makefile を作成して、-O2
をつけて ( コンパイルの警告を無視して) コンパイルしてください。
筆者は筆者のシステム用にソースを少し修正する必要がありました。:
a) XtGetValues 関数を呼んでいる行をコメントにしました。;
b) エンジンの横と縦の大きさを次の 2 行で 200 という固定値を指定しま
しょう。
<item><bf>結果:</bf> RPM の値。
<item>注意: このテストは X サーバの性能の厳密で、完璧なテストを意味
するものではありません。しかしながら、システムが画面上にカラーの
画素を出力する速度がどれくらい速いかの指標を得ます。知りたい事の
最小部分ではないでしょうか ? 
</itemize>

<!--
<sect2>BYTE Magazine's BYTEmark benchmarks: 
 -->
<sect2>BYTE マガジンの BYTEmark ベンチマーク: 
<p>
<!--
<itemize>
<item><bf>What:</bf> provides a good measure of CPU performance. Here 
is an excerpt from the documentation: <em>"These benchmarks are meant 
to expose the theoretical upper limit of the CPU, FPU, and memory 
architecture of a system. They cannot measure video, disk, or network 
throughput (those are the domains of a different set of benchmarks). 
You should, therefore, use the results of these tests as part, not 
all, of any evaluation of a system."</em>
<item>I have discarded the FPU test results since the Whetstone test 
included in UnixBench 4.10 is IMHO just as representative of FPU
performance.
<item>I have split the integer tests in two groups: those more 
representative of memory-cache-CPU performance and those more related
to CPU integer instructions.
 -->
<itemize>
<item><bf>何ものか:</bf> CPU 性能の良い測定を提供します。文書から
引用します。: <em>"これらのベンチマークはシステムの CPU, FPU, と
メモリアーキテクチャ の理論上な上限をあばく事を意味します。ビデオ,
ディスク, ネットワークスループットは測定できません。
(これは異なるベンチマークの領域です。)
従って、これらのテスト結果をシステムの評価の全部ではなく
一部として使いましょう。"</em>
<item>Whetstone テストが丁度 UnixBench 4.10 に含まれる FPU 性能を
表わしているので、FPU テスト結果は処分しました。
<item>整数テストは 2 つのグループに分けましょう。これらは
メモリキャッシュ-CPU 性能とそれらに関係する CPU 整数命令を表して
います。

<!--
<item>Test procedure: make with -O2. Run the test with <tt>./nbench 
&gt; myresults.dat</tt> or similar. Then, from myresults.dat, 
calculate geometric mean of STRING SORT, ASSIGNMENT and BITFIELD test 
indexes; this is the <bf>memory index</bf>; calculate the geometric 
mean of NUMERIC SORT, IDEA, HUFFMAN and FP EMULATION test indexes; 
this is the <bf>integer index</bf>.
<item><bf>Results:</bf> a memory index and an integer index
calculated as explained above.
</itemize>
 -->
<item>テスト手順: -O2 をつけて make しましょう。<tt>./nbench
&gt; myresults.dat</tt> 等としてテストを起動してください。
そのとき、myresults.dat から STRING SORT, ASSIGNMENT と BITFIELD
のテスト指標の幾何学平均を計算しましょう。これは<bf>メモリの指標</bf>
です。NUMERIC SORT, IDEA, HUFFMAN と FP EMULATION テスト指標の
幾何学平均を計算しましょう。これは <bf>整数の指標</bf> です。
<item><bf>結果:</bf> メモリの指標と整数の指標の計算は上記で説明
しました。
</itemize>

<!--
<sect1>Possible improvements
 -->
<sect1>考えられる改善
<p>

<!--
The ideal benchmark suite should run in a few minutes, with synthetic
benchmarks testing every subsystem separately and applications 
benchmarks providing results for different applications. It would 
also automatically generate a complete report and eventually email or
upload the report to a central database on the Web.
 -->
理想的なベンチマークスイートは各サブシステム別の合成ベンチマーク
と、異なるアプリケーション用の結果を得るアプリケーション
ベンチマークを数分で実行するでしょう。そのベンチマークスイート
は自動的に全てのレポートを作成し、最終的にレポートを Web 上の中央の
データベースに電子メールを送付し、更新するでしょう。

<!--
We are not really interested in portability across OS's here, but it
should at least run on all recent (&gt; 2.0.0) versions and flavors
(i386, Alpha, SPARC...) of Linux.

The test also has a very inconvenient "feature": the indexes for the
UnixBench and BYTEmark tests are based on different reference
machines. This is annoying, but does not disqualify the results for
either test.

The following areas are in need of improvements:
<enum>
<item>Networking benchmarks: if anybody has any idea about
benchmarking network performance in a simple, easy and reliable way,
with a short (less than 30 minutes to setup and run) test, please
contact me.
<item>X benchmarks: true 8, 16, 24 and 32 bits tests for X are
needed, that would exercise accelerator functions.
<item>Web server benchmarks: most linux users are aware that
commodity PC hardware + Linux + the Apache server daemon make up a
good combination for general-purpose Web servers, but benchmarks that
would indicate the performance of such machines are difficult to come
by. WebStone 2.01 seems to be a good candidate.
<item>Games performance: Doom or Quake benchmarks would be
interesting. I would prefer Doom benchmarks, since I have heard that
Quake includes special Pentium hand-optimized code, which makes it
unsuitable as a general-purpose benchmark for Linux systems. The
basic problem with Doom and Quake is that source code is not
available.
</enum>
 -->
我々は今までまったく OS 間の移植性について興味を持っていませんでした
が、ごく最近 Linux のバージョン (&gt; 2.0.0) と各種プラットフォーム
(i386, Alpha, Sparc 等) で少なくとも実行できます。

テストはまたとても不便な "特徴" を持っています。: UnixBench と
BYTEmark テストの指標は異なる参考マシンを基にしています。それぞれの
テストの結果を無効に出来ないことにいらいらします。

次の領域は改良のために必要です。:
<enum>
<item>ネットワークベンチマーク: 単純、簡単で信頼できる方法で短時間
(設定から実行までで 30 分以下で)のテストネットワーク性能の
ベンチマークについての着想をお持ちの方は、筆者まで連絡下さい。
<item>X ベンチマーク: X 用のアクセラレータ関数を働かせるには
真の 8, 16, 24 と 32 ビットが必要です。
<item>Web サーバベンチマーク: 殆んどの Linux ユーザは商用の PC 機材 +
 Linux + Apache サーバデーモンで汎用目的の Web サーバを実現しています
が、そのようなマシンでのベンチマークは異なる性能の指標を示します。
WebStone 2.01 は良い候補だと思います。
<item>ゲーム性能: Doom とか Quake のベンチマークは興味があるでしょう。
筆者は Quake が Pentium 用に手による最適化コードが含まれていると聞いて
いて Linux システムの汎用目的のベンチマークには向かないので、 Doom 
ベンチマークの準備をしています。Doom と Quake の基本的な問題はソース
が利用可能でないことです。
</enum>

<!--
<sect1>LBT Report Form
 -->
<sect1>LBT レポートの書式
<p>

<!--
Besides the tests, the benchmarking procedure would not be complete 
without a form describing the setup, so here it is (following the 
guidelines from the comp.benchmarks FAQ):
<code>LINUX BENCHMARKING TOOLKIT REPORT FORM
</code>
 -->
このテスト以外にも、設定を説明している書式なしではベンチマーク手順
は完全ではありません。よって、ここに示します。(次は
comp.benchmarks FAQ からのガイドラインです)

<code>LINUX BENCHMARKING TOOLKIT REPORT FORM
</code>
<code>CPU 
===
Vendor: 
Model: 
Core clock: 
Motherboard vendor: 
Mbd. model: 
Mbd. chipset: 
Bus type: 
Bus clock: 
Cache total: 
Cache type/speed: 
SMP (number of processors): 
</code>
<code>RAM 
=== 
Total: 
Type: 
Speed: 
</code>
<code>Disk 
==== 
Vendor: 
Model: 
Size: 
Interface: 
Driver/Settings: 
</code>
<code>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: 
</code>
<code>Kernel 
======
Version: 
Swap size:
</code>
<code>gcc 
=== 
Version: 
Options: 
libc version: 
</code>
<code>Test notes 
==========
</code>
<code>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:
</code>
<code>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. 
</code>

<!--
<sect1>Network performance tests 
 -->
<sect1>ネットワーク性能テスト
<p>

<!--
Testing network performance is a challenging task since it involves 
(to be expanded) 
at least two machines (server + client), hence at least twice the
time to setup and many more variables to control, etc... On a TCP/IP
ethernet network, I guess your best bet would be the ttcp package. Or
perhaps netperf.
 -->
ネットワーク性能のテストは、最低 2 つのマシン (サーバとクライアント)
を必要とするので 2 回設定し、たくさん管理するための数値を設定等しま
しょう。TCP/IP イーサネットネットワーク上では、最高の選択は ttcp
パッケージだと思います。若しくは netperf かもしれません。

<!--
<sect1>Symmetric Multi Processing (SMP) tests
 -->
<sect1>Symmetric Multi Processing (SMP) 対称型マルチプロセッサテスト
<p>

<!--
SMP tests are another challenge, and any benchmark specifically 
designed for SMP testing will have a hard time proving itself valid 
in real-life settings, since algorithms that can take advantage of 
multiprocessing are hard to come by. Linux started out as a
Uni-Processor (UP) OS but has lately developed strong support for
SMP. It seems later versions of the Linux kernel (&gt; 2.1.30 or
around that) will do "fine-grained" multiprocessing, but I have no
more information than that for the moment.
 -->
SMP テストはもう一つの挑戦です。SMP 用に特有に設計したベンチマーク
は実用になるマルチプロセッシングの優位性を発揮するアルゴリズムを
開発するのが困難なので SMP 自身を調査するのが困難な期間がありました。
Linux はユニ(単一)プロセッサ(UP) OS として開始しましたが、Linux
カーネルの最新版 (大体 &gt; 2.1.30)では "きめ細かい" マルチプロ
セッシングを行いますが、今の段階ではこれ以上の情報はありません。

<!--
According to David Niemi, <em>" ... shell8 does a good job at
comparing similar hardware/OS in SMP and UP modes."</em>
 -->
David Niemi によれば、<em>" ... shell8 が SMP と UP モードの
類似したハードウェア/OS を比較するのに良い仕事をします。"</em>

<!--
<sect>Example run and results
 -->
<sect>例題の実行と結果
<p>

<!--
The LBT was run on my home machine, a Pentium-class Linux box that I 
assembled myself and used to write this HOWTO. Here is the LBT Report
Form for this system:
 -->
自宅の自作ペンティアムマシンで LBT を実行し、そしてこの HOWTO を書き
ました。これはこのシステムの LBT レポートの書式です。:

<verb>LINUX BENCHMARKING TOOLKIT REPORT FORM
</verb>
<verb>CPU 
</verb>
<verb>===
</verb>
<verb>Vendor: Cyrix/IBM 
</verb>
<verb>Model: 6x86L P166+
</verb>
<verb>Core clock: 133 MHz
</verb>
<verb>Motherboard vendor: Elite Computer Systems (ECS)
</verb>
<verb>Mbd. model: P5VX-Be
</verb>
<verb>Mbd. chipset: Intel VX
</verb>
<verb>Bus type: PCI
</verb>
<verb>Bus clock: 33 MHz
</verb>
<verb>Cache total: 256 KB
</verb>
<verb>Cache type/speed: Pipeline burst 6 ns
</verb>
<verb>SMP (number of processors): 1
</verb>
<verb>RAM 
</verb>
<verb>===
</verb>
<verb>Total: 32 MB
</verb>
<verb>Type: EDO SIMMs
</verb>
<verb>Speed: 60 ns
</verb>
<verb>Disk 
</verb>
<verb>==== 
</verb>
<verb>Vendor: IBM
</verb>
<verb>Model: IBM-DAQA-33240
</verb>
<verb>Size: 3.2 GB
</verb>
<verb>Interface: EIDE
</verb>
<verb>Driver/Settings: Bus Master DMA mode 2
</verb>
<verb>Video board 
</verb>
<verb>=========== 
</verb>
<verb>Vendor: Generic S3
</verb>
<verb>Model: Trio64-V2
</verb>
<verb>Bus: PCI
</verb>
<verb>Video RAM type: 60 ns EDO DRAM
</verb>
<verb>Video RAM total: 2 MB
</verb>
<verb>X server vendor: XFree86
</verb>
<verb>X server version: 3.3
</verb>
<verb>X server chipset choice: S3 accelerated 
</verb>
<verb>Resolution/vert. refresh rate: 1152x864 @ 70 Hz
</verb>
<verb>Color depth: 16 bits
</verb>
<verb>Kernel 
</verb>
<verb>======
</verb>
<verb>Version: 2.0.29
</verb>
<verb>Swap size: 64 MB
</verb>
<verb>gcc 
</verb>
<verb>=== 
</verb>
<verb>Version: 2.7.2.1
</verb>
<verb>Options: -O2
</verb>
<verb>libc version: 5.4.23 
</verb>
<verb>Test notes 
</verb>
<verb>==========
</verb>
<verb>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.
</verb>
<verb>RESULTS 
</verb>
<verb>======== 
</verb>
<verb>Linux kernel 2.0.0 Compilation Time: 7m12s
</verb>
<verb>Whetstone Double Precision (FPU) INDEX: 50.2 MWIPS -&gt; 9.2
index
</verb>
<verb>UnixBench 4.10 system INDEX: 58.4
</verb>
<verb>Xengine: 790 RPM.
</verb>
<verb>BYTEmark integer INDEX: 1.50
</verb>
<verb>BYTEmark memory INDEX: 2.50
</verb>
<verb>Comments
</verb>
<verb>========= 
</verb>
<!--
<verb>This is a very stable system with homogeneous performance, 
ideal 
for home use and/or Linux development. I will report results 
with a 6x86MX processor as soon as I can get my hands on one!
</verb>
 -->
<verb>均質的な性能の家庭用かつ/または Linux 開発を行うのには
申し分なく、たいへん安定なシステムです。6x86MX プロセッサについて
出来るだけ自分の手で行って結果を報告します !
</verb>

<!--
<sect>Pitfalls and caveats of benchmarking 
 -->
<sect>ベンチマークの落とし穴と警告
<p>

<!--
After putting together this HOWTO I began to understand why the words 
"pitfalls" and "caveats" are so often associated with benchmarking...
 -->
この HOWTO を書いた後でベンチマークに関係している
 "落とし穴" と "警告" という言葉の意味を理解し始めました。

<!--
<sect1>Comparing apples and oranges 
 -->
<sect1>リンゴとオレンジを比べる事
<p>

<!--
Or should I say Apples and PCs ? This is so obvious and such an old 
dispute that I won't go into any details. I doubt the time it takes 
to load a word processor executable on a Mac compared to an average 
Pentium is a real measure of anything. Likewise booting Linux and 
Windows NT, etc... Try as much as possible to compare identical 
<bf>Linux</bf> machines with a single modification.
 -->
Apple と PC の事を言いましょうか ? あまりに明らかで詳細について
言及したくない昔の論争です。筆者は Mac 上のワードプロセッサの負荷を
平均的な Pentium と比べることが本当のベンチマークになる事を疑
っています。Linux と Windows NT 等の起動時間等も同様です。
一つの変更を行った <bf>Linux</bf> マシンを比較することを可能な限り
努力してください。

<!--
<sect1>Incomplete information 
 -->
<sect1>不完全な情報 
<p>

<!--
A single example will illustrate this very common mistake. One often 
reads in comp.os.linux.hardware the following or similar statement: 
"I just plugged in processor XYZ running at nnn MHz and now compiling 
the linux kernel only takes i minutes" (adjust XYZ, nnn and i as 
required). This is irritating, because no other information is given, 
i.e. we don't even know the amount of RAM, size of swap, other tasks 
running simultaneously, kernel version, modules selected, hard disk 
type, gcc version, etc... I recommend you use the LBT Report Form, 
which at least provides a standard information framework.
 -->
一つの例が非常に一般的な間違いを説明します。comp.os.linux.hardware
でしばしばみられることは、次のような似た記述があります。:
"nnn MHz の XYZ プロセッサを差し込んで linux カーネルをたった i 分
でコンパイル出来ました。" (XYZ, nnn, そして i は必要に応じて読み替
えてください) こいつはいらいらします。なぜなら例えば、メモリの容量、
スワップの容量、同時に動いているタスク、カーネルのバージョン、
モジュールの選択、ハードディスクの種類、gcc のバージョン等の情報が
無いからです。最低、標準的な情報の枠組みを提供している LBT レポート
の書式を使用することをお勧めします。

<!--
<sect1>Proprietary hardware/software 
 -->
<sect1>所有者のハードウェア/ソフトウェア
<p>

<!--
A well-known processor manufacturer once published results of 
benchmarks produced by a special, customized version of gcc. Ethical 
considerations apart, those results were meaningless, since 
100&percnt; of the Linux community would go on using the standard 
version of gcc. The same goes for proprietary hardware. Benchmarking 
is much more useful when it deals with off-the-shelf hardware and 
free (in the GNU/GPL sense) software.
 -->
良く知られているプロセッサ製造会社はかつて特別なカスタマイズした
gcc で作成したベンチマークの結果を公表しました。倫理的に考えれば
これらの結果は標準的なバージョンの gcc を使っている Linux 
コミュニティでは 100&percnt; 意味がありません。同じことは所有者の
ハードウェアにも言えます。ベンチマークは既製のハードウェアと
フリー (GNU/GPL の考えによる) ソフトウェアにも適応できるからです。

<!--
<sect1>Relevance 
 -->
<sect1>妥当性 
<p>

<!--
We are talking Linux, right ? So we should forget about benchmarks 
produced on other operating systems (this is a special case of the 
"Comparing apples and oranges" pitfall above). Also, if one is going 
to benchmark Web server performance, there is no need to quote FPU
performance and other irrelevant information. In such cases, less is 
more. Also, you do <bf>not</bf> need to mention the age of your cat, 
your mood while benchmarking, etc..
 -->
Linux について話しています、いいですね ? 従って他のオペレーティング
システムで作成したベンチマークに関しては忘れましょう (これは上記の
"リンゴとオレンジを比べる" 所の落とし穴の特別な場合になります)。
また、Web サーバの性能に言及する場合は、FPU 性能や他の重要でない
情報を引き合いに出す必要はありません。このような場合は、
過ぎたるは及ばざるが如しです。また、ご自分の猫の年齢や
ご自身の機嫌等にも言及する必要も <bf>ありません</bf> 。

<!--
<sect1>Variance
 -->
<sect1>分散
<p>

<!--
This again has to do with reproducing results. If everytime you run
benchmark Z on the same system, you get significantly different
results (say, &gt; 2 &percnt;), then benchmark Z is not sufficiently
accurate and probably needs a redesign. If you still want to use
benchmark Z, you should at least explicitly mention the variations in
results, preferably as a percentage of the average result, and the
possible explanations for these variations. If you do<bf> not
</bf>point out the variance for a given benchmark and its possible
causes, the basic assumption is that, without taking any special
precautions, it is &lt; 1 &percnt;.
 -->
これは結果の再作成に用います。同じシステムで Z ベンチマークを毎回
実行する場合、かなり違った結果 (&gt; 2 &percnt;) を得るでしょう。
その時、Z ベンチマークは十分な精度はでないし、多分再開発する必要も
ないでしょう。まだ Z ベンチマークを使用したい場合は結果の変動を
はっきりと言及するべきで、むしろ結果の平均の百分率とこれらの変動を
確率的説明に言及するべきでしょう。与えられたベンチマークの分散を
指摘でき<bf>ない</bf>場合とできたとしても、特別な警戒について議論
なしに基本的な仮定として分散は 1 &percnt; 以下です。

<!--
<sect1>Wrong statistical/logical inference
 -->
<sect1>不正な統計的/論理的推定
<p>

<!--
There are all sorts of tricks to produce false statements from
seemingly harmless, undisputable benchmark results. This is why the
LBT includes just a single Comments field for such judgments. It is
then up to each one's scrutiny and good sense to sort the data and
come to any conclusion.
 -->
表面上無害な、明白なベンチマーク結果からベンチマークが失敗だという
結論を出す全ての種類の技があります。これは LBT がこのような判断のた
めにひとつの Comments 欄がある理由なのです。その時、それぞれの精密
な調査するまでデータをソートする良い考え方がいくつかの結論を出す事
になります。

<!--
<sect>FAQ 
 -->
<sect>FAQ 

<p>
<descrip>
<!--
<tag>Q1.</tag>How does Linux compare to ... (choose any other OS)
when it comes to performance ?
<tag>A:</tag>Comparing the performance of different OS's with Linux
is a good way to start a discussion on comp.os.linux.advocacy that
<bf>inevitably</bf> degenerates into a flame war. The choice of an OS
for a particular system running a given set of applications can never
be based solely on performance figures. Performance is one amongst a
number of criteria that will be used to choose an OS, and usually is
<bf>not</bf> the most significant, specially when comparing Linux to
non-Unix OS's. Also, comparable performance figures for different
OS's are very difficult or even impossible to produce in most cases.
When comparing Linux to other Unix variants, the issue is moot: the
other "victims" are usually BSD variants, Sun Solaris or Sun OS,
NextStep, AIX or HP/UX, none of which is GPLed or will run on as many
platforms as Linux.
 -->
<tag>Q1.</tag>Linux と ... (他の OS を選択して) どのように性能比較
したら良いでしょう ?
<tag>A:</tag> Linux と他の OS の性能を比較することは
comp.os.linux.advocacy で感情的な戦いの議論をはじめるのに良い
方法です。[訳注:感情的な戦いは好ましくないので逆説的な言い方ですね]
与えられたアプリケーションが稼働する各自のシステムの OS の選択は
性能の数値と独立してはいません。性能は OS を選択する上での幾つかの
基準の内の一つで、通常はわざわざ Linux と他の Unix でない OS を比較
するときには、ほとんど意味のあることでは<bf>ありません</bf>。
また、異なる OS で類似の性能の数値は大変異なるか若しくは、殆んどの
場合、製作する事さえまったく不可能です。Linux と 他の Unix の変種
を比較するときは、重要な点は議論の余地がある問題点で: 
対する "犠牲者" はいつも BSD の変種である Sun Solaris 又は Sun OS,
NextStep, AIX 若しくは HP/UX で、それらは GPL に準拠してなかったり
多くは Linux の稼働しないプラットフォームで稼働するものです。

<!--
<tag>Q2.</tag>Is there any single figure of merit for Linux systems ?
<tag>A:</tag>No, thankfully nobody has yet come up with a Lhinuxstone 
(tm) measurement. And if there was one, it would not make much sense: 
Linux systems are used for many different tasks, from heavily loaded 
Web servers to graphics workstations for individual use. No single 
figure of merit can describe the performance of a Linux system under 
such different situations. 
 -->
<tag>Q2.</tag>Linux システム用の一つの価値ある数値はありますか ?
<tag>A:</tag>いいえ、ありがたいことに誰も Lhinuxstone (tm) 測定値
のようなものは出てきていません。そのようなものがあったとしても
Web サーバが個々のグラフィックワークステーションへ高い負荷をかける
ような Linux システムは多くの色々なタスクが動作しています。このよ
うないろいろな状況にある Linux システムについて利点の比喩的表現は
ありません。

<!--
<tag>Q3.</tag>Then, how about a dozen figures summarizing the
performance of diverse Linux systems ? 
<tag>A:</tag>That would be the ideal situation. I would like to see 
that come true. In fact, the Washington Area Unix User Group has
setup a <htmlurl url="http://wauug.erols.com/bench " name=" Web site
">for the Linux Benchmarking Project, and should have an on-line
database for Linux benchmark results Real Soon Now.
 -->
<tag>Q3.</tag>この時、どうやって多様な Linux システムの色々な
性能を幾つかの数字にまとめたら良いでしょう ?
<tag>A:</tag>理想的な状況を仮定します。現実にしたいと思います。
事実、Washington Area Unix User Group が
<htmlurl url="http://wauug.erols.com/bench " name=" Web サイト ">
を Linux Benchmarking Project のために設定していて、Linux のベンチ
マーク結果用のオンラインデータベースが本当にすぐに持てるようになる
でしょう。

<!--
<tag>Q4.</tag>... BogoMips ... ?
<tag>A:</tag>BogoMips has nothing to do with the performance of your 
system. Check the BogoMips Mini-HOWTO. 
 -->
<tag>Q4.</tag>BogoMips って ?
<tag>A:</tag>BogoMips はお手元のシステムの性能を表すものではあり
ません。BogoMips Mini-HOWTO を調べてください。

<!--
<tag>Q5.</tag>What is the "best" benchmark for Linux ?
<tag>A:</tag>It all depends on which performance aspect of a Linux 
system one wants to measure. There are different benchmarks to 
measure the network (Ethernet sustained transfer rates), file server 
(NFS), disk I/O, FPU, integer, graphics, 3D, processor-memory 
bandwidth, CAD performance, transaction time, SQL performance, Web 
server performance, real-time performance, CD-ROM performance, Quake 
performance (!), etc ... AFAIK no benchmark suite exists for Linux
that supports all these tests.
 -->
<tag>Q5.</tag>Linux 用の "最高の" ベンチマークは何ですか ?
<tag>A:</tag>Linux システムのどの角度の性能を計りたいかによります。
ネットワーク性能 (一様の転送速度の Ethernet), ファイルサーバ (NFS),
ディスク入出力, FPU, 整数, グラフィックス, 3D, プロセッサ-メモリ
帯域幅, CAD 性能, トランザクション時間, SQL 性能, Web サーバ性能, 
実時間性能, CD-ROM 性能, 耐震性能 (!), 等などを網羅する Linux 用
のベンチマークスイートは筆者が知る限り今までありません。

<!--
<tag>Q6.</tag>What is the fastest processor under Linux ?
<tag>A:</tag>Fastest at what task ? If one is heavily 
number-crunching oriented, a very high clock rate Alpha (600 MHz and 
going) should be faster than anything else, since Alphas have been 
designed for that kind of performance. If, on the other hand, one 
wants to put together a very fast news server, it is probable that 
the choice of a fast hard disk subsystem and lots of RAM will result 
in higher performance improvements than a change of processor, for 
the same amount of &dollar;. 
 -->
<tag>Q6.</tag>Linux 下で最高速のプロセッサは何ですか ?
<tag>A:</tag>どの業務で最高速なのでしょう ? 重い数値計算よりの業務
の場合は Alpha が該当する業務向けに設計されているので、高クロックの
Alpha (600 MHz 以上) が他よりは速いでしょう。また一方、速いニュース
サーバがほしい場合は高速なディスクサブシステムを選択し沢山のメモリ
を積んだシステムが同じ費用でプロセッサを変更するよりはより高い性能
を結果として残すでしょう。

<!--
<tag>Q7.</tag>Let me rephrase the question, then: is there a
processor that is fastest for general purpose applications ? 
<tag>A:</tag>This is a tricky question but it takes a very simple 
answer: <bf>NO</bf>. One can always design a faster system even for 
general purpose applications, independent of the processor. Usually, 
all other things being equal, higher clock rates will result in 
higher performance systems (and more headaches too). Taking out an 
old 100 MHz Pentium from an (usually not) upgradable motherboard, and 
plugging in the 200 MHz version, one should feel the extra "hummph". 
Of course, if one had only 8 MBytes of RAM on the original system,
the same money would have been more wisely invested by purchasing
extra SIMMs...
 -->
<tag>Q7.</tag>質問を言い換えると、つまり: 
汎用的なアプリケーションで最高速のプロセッサは何ですか ?
<tag>A:</tag>油断のならない質問ですが、とても単純な答があります。:
<bf>ありません</bf>。いつも汎用的なアプリケーション用に高速な
システムを設計したとしてもプロセッサ依存になります。通常、
ほかの部分は高いクロック速度が高性能のシステムを結果として生じます。
(頭痛も起きますけど)。 古い 100 MHz の Pentium をアップグレード
可能な (通常違いますが) マザーボードから取り出して, 200 MHz 版を
さした時には余分に "ふーん" と感じるでしょう。勿論、8 メガバイト
のメモリしかない元のシステムに、同額の投資で余分に SIMM を買った
方がより賢いと思います。

<!--
<tag>Q8.</tag>So clock rates influence the performance of a system ?
<tag>A:</tag>For most tasks except for NOP empty loops (BTW these get 
removed by modern optimizing compilers), an increase in clock rate 
(with the same processor architecture) will not give you a linear
increase in performance. Very small processor intensive programs that
will fit entirely in the primary cache inside the processor (the L1
cache, usually 8 or 16 K), with a high locality of data and very
little I/O will have a performance increase equivalent to the clock
rate increase, but most "true" programs are much larger than that,
have loops that do not fit in the L1 cache, share the L2 (external)
cache with other processes, depend on external components and will
give much smaller performance increases. This is because the L1 cache
(usually) runs at the same clock rate as the processor, whereas most
L2 caches and all other subsystems (DRAM, for example) will run
asynchronously at lower clock rates. Some processors even have L1, L2
and L3 caches !
 -->
<tag>Q8.</tag>そんなにクロック周波数がシステムの性能に影響がありますか?
<tag>A:</tag>NOP 命令のループを除いたほとんどのタスクでは (新しい
最適化コンパイラは NOP 命令を取り除くけれど) 、(同じプロセッサ
アーキテクチャでは) クロック周波数が増加
すると線形に性能向上します。プロセッサ内蔵の 1 次キャッシュ
(L1 キャッシュ、通常 8 または 16 K) に完全に
はまりこんでしまう、データが高度に局所化していて入出力がとても少ない
ような、十分小さなプロセッサ集中的なプログラム
はクロック周波数の増加と同時に性能向上しますが、殆んどの "本物の"
プログラムはそのようなプログラムよりかなり大きく L1 キャッシュに
入らないほど大きいループを持っていて、(外部の) L2 キャッシュを
ほかのプロセスと共有しています。よって外部の構成要素に依存し少し
性能が向上するかもしれません。したがってプロセッサと同一クロック
周波数で L1 キャッシュは (通常) 動作していますが、ところが L2 
キャッシュと
他のサブシステム (例えば DRAM) はより低いクロック周波数で非同期に
動作しています。幾つかのプロセッサは L1, L2 と L3 キャッシュさえ
持っています。

<!--
<tag>Q9.</tag>OK, then, one last question on that matter: which is
the processor with the best price/performance ratio for general 
purpose Linux use ? 
<tag>A:</tag>Defining "general purpose Linux use" in not an easy 
thing ! For any particular application, there is always a processor 
with The Best price/performance ratio at any given time, but it
changes rather frequently as manufacturers release new processors
and/or change prices, so answering Processor XYZ running at n MHz
would be a snapshot answer. However, the price of the processor is
insignificant when compared to the price of the whole system one will
be putting together. So, really, the question should be how can one
maximize the price/performance ratio for a given system ? And the
answer to that question depends heavily on the minimum performance
requirements and/or maximum cost established for the configuration
being considered. Sometimes, off-the-shelf hardware will not meet
minimum performance requirements and more expensive RISC systems will
be the only alternative. And then very often the bottleneck is not
processor performance, but disk I/O... For home use, I recommend a
balanced, homogeneous system for overall performance (now go figure
what I mean by balanced and homogeneous :-); the choice of a
processor is an important decision , but no more than choosing hard
disk type and capacity, amount of RAM, video card, etc...
 -->
<tag>Q9.</tag>分かりました。では、最後の質問を次の事象について:
一般的な目的向け Linux の最高のコストパフォーマンスのプロセッサは何で
しょう ?
<tag>A:</tag>"一般的な目的向け Linux" の定義は簡単なものではありませ
ん。特定のアプリケーション向けなら、与えられた時間で最高のコスト
パフォーマンスは考えられますが、製造会社は新しいプロセッサをかなり
頻繁に発表し、価格を変更するので n MHz で動作するプロセッサ XYZ 
という舌足らずの
答が出てきます。しかしながら、プロセッサの価格はシステムを合わせた
全体の価格の中ではささいなものでしょう。従って、実際には、質問は
どうやってシステムのコストパフォーマンスを最大にするか ? ですね。
そして、最低の性能の必要条件と/または考えている構成が最大コスト
に納まることに深く依存していますね。時々、既製のハードウェアでは
最低性能要件に出会うことは無いでしょう。高価な RISC の
システムは選択肢にしかすぎません。そしてボトルネックの殆んどは
プロセッサの性能ではなくディスクの入出力です。自宅で使うには、
全体の性能が安定
した、均質的なシステムをお勧めします。(安定と均質が何をさしているか
思い浮かべてください :-); プロセッサの選択は重要な決定事項ですが、
ハードディスクの型と容量、メモリの量、ビデオカード等を選択するのも
大切です。

<!--
<tag>Q10.</tag>What is a "significant" increase in performance ?
<tag>A:</tag>I would say that anything under 1&percnt; is not 
significant (could be described as "marginal"). We, humans, will 
hardly perceive the difference between two systems with a 5 &percnt; 
difference in response time. Of course some hard-core benchmarkers 
are not humans and will tell you that, when comparing systems with 
65.9 and 66.5 CPU performance indexes, the later is "definitely
faster".
 -->
<tag>Q10.</tag>性能において "意味のある" 増分とは何でしょう ?
<tag>A:</tag>1&percnt; 以下のものを重要とは言いません("わずかな"
と記述することにします)。我々、人間は応答時間が 5 &percnt; 異なるとき
はっきりと二つのシステムの違いを知覚できます。勿論、いくつかの徹底
したベンチマークは人間ではないですからシステムを比較して性能指標が
65.9 と 66.5 という場合は後者を "明確に高速である" と言います。

<!--
<tag>Q11.</tag>How do I obtain "significant" increases in performance
at the lowest cost ? 
<tag>A:</tag>Since most source code is available for Linux, careful 
examination and algorithmic redesign of key subroutines could yield 
order-of-magnitude increases in performance in some cases. If one is 
dealing with a commercial project and does not wish to delve deeply 
in C source code a <bf>Linux consultant should be called in</bf>. See 
the Consultants-HOWTO. 
 -->
<tag>Q11.</tag>最低の費用で性能においてどのようにして "意味のある"
増分を得られるでしょう ?
<tag>A:</tag>Linux のソースコードが利用可能なのだから、注意深く
鍵となるサブルーチンのアルゴリズムを再設計すればいくつかの場合に
性能が驚くほど向上するかもしれません。商用プロジェクトと関係する
か C のソースコードを深く探究するのがイヤなら
<bf>Linux コンサルタントを呼ぶべきでしょう</bf>。
Consultants-HOWTO を参照してください。
</descrip>

<!--
<sect>Glossary
 -->
<sect>付録
<p>
<itemize>
<!--
<item><bf>Architecture:</bf> a description of the instruction set,
register set and general features of a processor.
<item><bf>Benchmark</bf>: a well-documented, standardized procedure
for computer performance measurements.
<item><bf>Efficiency</bf>: usually describes the &percnt; of a given
computing task that gets executed per clock cycle on a specific
architecture.
<item><bf>FPU</bf>: Floating Point Unit. Hardware component dedicated
to floating-point calculations.
 -->
<item><bf>アーキテクチャ(Architecture):</bf> 命令セット、レジスタ
セットとプロセッサの一般的な機能の種類。
<item><bf>ベンチマーク</bf>: コンピュータの性能測定に関する
良く文書化された、標準化された手順
<item><bf>効率</bf>: 特定のアーキテクチャでのクロックサイクル当りの
計算の実行結果の百分率で通常記述します。
<item><bf>FPU</bf>: 浮動小数点ユニット(Floating Point Unit)。
浮動小数点計算専用のハードウェア構成要素。
<!--
<item><bf>GPL</bf> (or GNU/GPL): GNU General Public License. A
software license that provides a high degree of freedom in a
collaborative software development effort. A copy of the GNU/GPL
license is provided with the Linux kernel source (see the file
COPYING). By extension, a software package is said to be GPLed if it
is placed under the GNU/GPL license.
<item><bf>Index</bf>: a measurement of relative performance. All
measurements are normalized against those for a reference system that
has index 1.0.
<item><bf>MFLOPS</bf>: Millions of FLoating-point Operations Per
Second. A measure of floating-point computer performance. Also GFLOPS
(Giga-FLOPS), TFLOPS (Tera-FLOPS), KFLOPS (Kilo-FLOPS). One should
always specify Single or Double precision when using FLOPS ratings.
 -->
<item><bf>GPL</bf> (又は GNU/GPL): GNU General Public License。
協調ソフトウェア開発の努力の成果に高い自由度を提供するソフトウェア
ライセンス。GNU/GPL ライセンスは Linux カーネルソースと共に提供され
(COPYING ファイルを参照してください) ています。拡張されて、GNU/GPL 
ライセンスの下に置かれている場合はソフトウェアパッケージが GPL に
従っていると呼ばれます。
<item><bf>指標 (Index)</bf>: 相対性能の大きさ。全ての大きさは
指標が 1.0 である参考システムに対して基準に合わせます。
<item><bf>MFLOPS</bf>: Millions of FLoating-point Operations Per
Second の略(メガフロップス)。秒当たりの浮動小数点命令の実行回数の
百万回単位量。浮動小数点計算性能の大きさ。
同様に GFLOPS は ギガ(Giga)-FLOPS, TFLOPS はテラ(Tera)-FLOPS, 
KFLOPS はキロ(Kilo)-FLOPS のことです。FLOPS 量を使うときは常に
単精度若しくは倍精度であるか明記すべきです。
<!--
<item><bf>MIPS</bf>: Millions of Instructions Per Second. Considered
one of the worst measurements of computer performance, since it
ignores CPU architecture efficiency issues, I/O bound operations, OS
overhead, etc...
<item><bf>Performance</bf>: the time needed by a system
(hardware/software combination) to execute a given computing task.
<item><bf>Relevance</bf>: information provided by a particular
benchmark or benchmark run on a specific performance aspect of a
system. For example, an FPU benchmark is considered irrelevant to
measure Web server performance.
 -->
<item><bf>MIPS</bf>: Millions of Instructions Per Second の略
(ミップス)。 CPU アーキテクチャの効率の問題点、入出力周りの操作、
OS のオーバヘッド等を無視した計算性能の不正な大きさ。
<item><bf>性能</bf>: 与えられた計算タスクを実行するシステム
(ハードウェア/ソフトウェアの組み合わせ) に必要な時間。
<item><bf>分散</bf>: 特定のベンチマークによって提供される情報
またはシステムの特定の性能の見地。例えば、FPU ベンチマークは
Web サーバの性能測定には不適切です。
<!--
<item><bf>Resolution</bf>: the smallest performance variation that
can be measured by a specific benchmark on a given system.
<item><bf>Single Figure of Merit</bf>: when a single figure is enough
to summarize a performance aspect of a system, it is called a Single
Figure of Merit. May be valid to summarize the performance of a
particular subsystem of a computer (e.g. the Single Figure of Merit
for an FPU), or to summarize the results of a set of tests that
measure a distinct feature of a computer (e.g. 3D graphics
performance), but cannot be used to describe the general performance
of a system.
 -->
<item><bf>解像度</bf>: 与えられたシステム上での特定のベンチマーク
で測定された最小の性能の変動量。
<item><bf>価値ある一つの数値</bf>: システムの性能の様相を要約するに
十分な一つの数値があれば、それを価値ある一つの数値と呼びます。
コンピュータのある特定のサブシステムの性能を要約することができた場合、
(例えば、FPU 用の価値ある一つの数値) 又は、他とまったく別なコンピ
ュータの機能のテストを組み合わせた結果の要約(例えば、3D グラフィック
性能) がある場合はありますが、システム全般の性能を記述出来るものは
ありません。
<!--
<item><bf>Stability</bf>: the quality of a program that does what
it's supposed to do, has no memory leaks and does not crash the
machine. Much sought-after, very hard to attain. More important than
performance.
<item><bf>Variance</bf>: statistical measurement of the precision
margin for a given benchmark.
 -->
<item><bf>安定性</bf>: メモリリークがない事とマシンを停めてしまわ
ないようなプログラムの品質。とても珍重され、達成するのが難しいです。
性能よりも重要です。
<item><bf>分散</bf> 与えられたベンチマークの精度の余地の統計量。
</itemize>
<!--
<sect>Copyright, acknowledgments and miscellaneous
 -->
<sect>著作権表示, 謝辞 と 雑録
<p>
<!--
<sect1>How this document was produced
 -->
<sect1>何故この文書が作られたか
<p>

<!--
The first step was reading section 4 "Writing and submitting a HOWTO" 
of the HOWTO Index, by Greg Hankins.
 -->
Greg Hankins による HOWTO の目次の "Writing and submitting a HOWTO"
の 4 章を読んだのが最初です。

<!--
I knew absolutely nothing about SGML or LaTeX, but was tempted to use 
an automated documentation generation package after reading the 
various comments about SGML-Tools. However, inserting tags manually 
in a document reminds me of the days I hand-assembled a 512 byte 
monitor program for a now defunct 8-bit microprocessor, so I got hold 
of the LyX sources, compiled it, and used its LinuxDoc mode. Highly 
recommended combination: <bf>LyX and SGML-Tools</bf>.
 -->
筆者は SGML も LaTeX も全く知らなかったけど、SGML-Tools に関する
色々な説明を読んだ後で、自動で文書を生成してくれるパッケージが
あることが分かりました。しかしながらタグを文書の中に手で挿入する
ことは、今は現存しない 8-ビットマイクロプロセッサの 512 バイトの
モニタプログラムをハンドアセンブルしていた頃を思い出させたので、
LyX のソースを持ってきてコンパイルし LinuxDoc モードにして使いま
した。<bf>LyX と SGML-Tools</bf> の組合わせを強くお勧めします。
<newline>
[訳注: LyX 日本語版はありませんが、LinuxDoc-SGML 日本語版(パッチ)
があります。SGML-Tools 日本語版はありません。]

<!--
<sect1>Copyright
 -->
<sect1>著作権表示
<p>

<!--
The Linux Benchmarking HOWTO is copyright (C) 1997 by AndrDerrick
Balsa. Linux HOWTO documents may be reproduced and distributed in
whole or in part, in any medium physical or electronic, as long as
this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions.
 -->
The Linux Benchmarking HOWTO is copyright (C) 1997 by AndrDerrick
Balsa. 
Linux HOWTO 文書は全部若しくは部分でもどんな物理媒体、電子媒体でも
この著作権表示をそっくり保持するかぎり複写と配布が可能です。
商用再分配を許諾し奨励します;　しかしながら著者は商用再配布を
行う時は通知して頂きたく思います。

<!--
All translations, derivative works, or aggregate works incorporating 
any Linux HOWTO documents must be covered under this copyright 
notice. That is, you may not produce a derivative work from a HOWTO 
and impose additional restrictions on its distribution. Exceptions to 
these rules may be granted under certain conditions; please contact 
the Linux HOWTO coordinator at the address given below.
 -->
翻訳、派生的な著作 または幾つかの Linux HOWTO 文書を組織化し集約した
著作の全てはこの文書の著作権表示の保護を受けます。これは HOWTO から
派生的な作業を生ませないものでなく、文書の配布に制限を追加するもの
ではありません。これらの規則の例外は正当な条件で承諾する事であり、
以下に示すアドレスの Linux HOWTO のまとめ役に連絡を取ってください。

<!--
In short, we wish to promote dissemination of this information 
through as many channels as possible. However, we do wish to retain 
copyright on the HOWTO documents, and would like to be notified of 
any plans to redistribute the HOWTOs. 
 -->
手短に言えば、我々は可能な限り多くの経路を通じてこの情報が普及、
促進することを願っています。しかしながら、HOWTO 文書の著作権が
保持され、この HOWTO 文書の再配布計画の通知を頂きたく思います。

<!--
If you have questions, please contact Greg Hankins, the Linux HOWTO 
coordinator, at <url url="mailto:gregh@sunsite.unc.edu"
name="gregh@sunsite.unc.edu">.
 -->
質問があるときは、Linux HOWTO まとめ役である Greg Hankins
に連絡を取ってください。電子メール経由で
<url url="mailto:gregh@sunsite.unc.edu"
name="gregh@sunsite.unc.edu"> までお願いします。

<!--
<sect1>New versions of this document
 -->
<sect1>この文書の新版
<p>

<!--
New versions of the Linux Benchmarking-HOWTO will be placed on 
sunsite.unc.edu and mirror sites. There are other formats, such as a 
Postscript and dvi version in the other-formats directory. The Linux 
Benchmarking-HOWTO is also available for WWW clients such as Grail, a 
Web browser written in <url url="http://www.python.org"
name="Python">. It will also be posted regularly to
comp.os.linux.answers.
 -->
Linux Benchmarking-HOWTO の新版は sunsite.unc.edu とそのミラーサイト
に置かれます。他の書式ではポストスクリプトと dvi 版が　other-formats 
ディレクトリに置かれています。Linux Benchmarking-HOWTO は
<url url="http://www.python.org"
name="Python">で
書かれた Grail のような Web ブラウザからも利用可能です。
この文書の新版は comp.os.linux.answers に定期的に投稿されます。

<!--
<sect1>Feedback
 -->
<sect1>フィードバック
<p>

<!--
Suggestions, corrections, additions wanted. Contributors wanted and 
acknowledged. Flames not wanted.
 -->
提案、修正、追加を欲しています。貢献者を募集していますし感謝していま
す。激論となるのは望んでいません。
<!--
I can always be reached at andrewbalsa@usa.net.
 -->
筆者はいつでも andrewbalsa@usa.net にいます。
<!--
<sect1>Acknowledgments
 -->
<sect1>謝辞
<p>

<!--
I want to thank Jeremy Chatfield from Xi Graphics, Uwe Mayer, David
Niemi and Kazuyuki Okamoto for various contributions and suggestions.
 -->
色々な貢献と提案をいただきました
Jeremy Chatfield (Xi Graphics 所属), Uwe Mayer, David Niemi, と 
Kazuyuki Okamoto に感謝したいです。

<!--
I also want to express my gratitude to Greg Hankins, the Linux HOWTO
coordinator and one of the main contributors to the SGML-tools
package, and of course to Linus Torvalds and the active Linux
community. This HOWTO is my way of giving back.
 -->
また、Linux HOWTO のまとめ役と SGML-tools パッケージの寄付者の一人
である Greg Hankinsと, Linus Torvalds と活発な Linux コミュニティ
にも感謝を表したいです。この HOWTO が恩返しになるように。

<!--
<sect1>Disclaimer
 -->
<sect1>放棄声明文
<p>

<!--
Your mileage may, and <bf>will</bf> vary. Be aware that benchmarking
is a controversial subject and a great time-and-energy consuming
activity.
 -->
読者の利益は様々<bf>でしょう</bf>。ベンチマークは物議をかもす題目であり
、大きな時間とエネルギーを消費する活動だと理解して下さい。

<!--
<sect1>Trademarks
 -->
<sect1>商標
<p>

<!--
Pentium and Windows NT are trademarks of Intel and Microsoft 
Corporations respectively. 

BYTE and BYTEmark are trademarks of McGraw-Hill, Inc.

Cyrix and 6x86 are trademarks of Cyrix Corporation.

Linux actually is a registered trademark of Linus Torvalds :-)
 -->
Pentium と Windows NT は Intel Corporation と Microsoft Corporation
の商標です。

Cyrix と 6x86 は Cyrix Corporation の商標です。

Linux は実際は Linus Torvalds の登録商標です。:-)

</article>
