XWIN II Weblog

Hyper-Threading──嗚呼、Freeze模様（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行 II」

巻頭言 981　「Hyper-Threading──嗚呼、Freeze模様」

Super πとTMPGEncの同時実行テストで思わぬトラブルを招来してしまったが、これが「Dual Xeon 2.20GHz ＋ Tyan Thunder i860 S2603 ＋ Hyper-Threading OFF」によるものかを検証したい。
（ところで前回（昨日）、「場合によっては、午後あたりに加筆するかもしれないが──」としていたが、単に記述するだけならそれも可能だったのだが、今回は帰宅して自宅マシンでの検証を要するために結果としてできなかった。帰宅したのが午前様では、無理というものであったといえようか。）

Super πとTMPGEnc同時実行テストにおいて、4CPU状態でまったく問題が発生しないのに、「/numproc=2」オプションを追加して強制的に 2CPU状態（いずれも物理プロセッサ有効）にすると、Freezeしてしまう。ちなみにこのようなFreezeは、Thunder i860をベースにしたDual Xeonマシンでは、Xeon 1.70GHzを使っていた時まで含めて初めてのことである。それだけ安定度の高かったものが、こうもあっさりFreezeしてしまうということは、単純に考えても強制的に2CPU状態にしたことが原因であるとしか考えられない。

本来なら、BIOS設定で「Jackson Techonogy」をEnabledからDisabledにすればいいのだろうが、以前の巻頭言でもふれたように、BIOS設定での「Jackson Techonogy」をどちらにしても、Windows XPはHyper-Threadingテクノロジを有効にしてしまう。なので、このBIOS設定をEnabledからDisabledに変えても意味はないと思いつつ、念のためということで「Jackson Techonogy」をEnabledからDisabledに設定変更し、かつ「/numproc=2」オプションを追加して2CPU状態で起動した Windows XP Professionalで、再度同時実行テストを行った。しかし、結果は同じようにFreezeしてしまったのである（なお、Super πとTMPGEncのCPU割り当てをそれぞれ独立して与えても、結果は変わらなかった）。

Super πとTMPGEnc同時実行中Freezeした画面写真（擬似的にHyper-ThreadingをOFF）

やはり、Thunder i860のBIOS（バージョン1.04）での「Jackson Technology」設定は、Windows XPにおいては事実上無意味であることが再確認できたに過ぎなかった。それでは、2CPUであることが問題という可能性を消し去るため、Windows XP Home Editionで起動し、Hyper-Threadingを有効にした2CPU状態（物理プロセッサとしては１つ、論理プロセッサとして２つ）で同時実行テストを行った。結果は予想どおり、無事にテストは終了し、実行タイムはSuper π（52万桁）が59秒、TMPGEncが1分47秒という結果となり、Dualプロセッサでの実行タイムとは大幅に遅れたことから、物理プロセッサは１つであることが裏付けられた。厳密に言えば、OS環境が異なっているので、今度はWindows XP Home Editionのboot.ini中に「/numproc=1」と設定することで、強制的に1CPU状態とし、Hyper-ThreadingをOFFにして同時実行テストを行った。これでFreezeすれば、ほぼ間違いなく、Hyper-Threadingがらみの問題となるが、これも予想どおり処理の途中でFreezeした。
以上のことから、次のことがいえるだろう。

『Hyper-Threadingテクノロジが有効にされているXeonプロセッサをTyan Thunder i860（BIOSバージョン1.04）に搭載し、OSにWindows XPをインストールすると、BIOSの設定いかんにかかわらず、常にHyper-Threadingテクノロジは有効になり、OSからは論理プロセッサの総数が認識されるようになる。これに「/numproc」オプションで、OSのサポートするCPU数を減らし、見かけ上物理プロセッサだけを有効にした状態で、Super πとTMPGEncを同時実行すると、処理の途中で常にFreezeする。』

なぜ、Freezeするのか？という根本的な原因は、とにかくエラーログがまったく出力されず、完全なFreeze状態になってしまうため、どういった理由でFreezeしたかはわからない。ICEを利用したり、リモートデバッグを行う等すれば、ある程度原因の取っ掛かりを掴めるかも知れないが、とてもではないがそこまで行う労力は割けない。
とはいいつつも、理由がまったくわからないわけでもない。推測ではあるが、おそらく「/numproc」オプションでCPU数を制限することが、 Hyper-Threadingテクノロジを考慮に入れていないか、またはThunder i860のBIOS設定でHyper-Threadingテクノロジを上手に殺していないための不具合ではないかと思われる。いずれにしても、 Hyper-Threadingテクノロジを下手に制限しない方がいいということだけは間違いないだろう。

聞くところによれば、Hyper-Threadingテクノロジは、システム（BIOS）上の設定でサーバ向けでなければEnableされないという話があるが、私のThunder i860の環境においては、現段階でという条件付きだが、下手にHyper-ThreadingテクノロジをDisableする方が却って不具合が起こるという結果となった。いや、むしろBIOSでDisableにしても、Windows XPがHyper-Threadingテクノロジを有効にしてしまうことが問題かもしれない。いやいや、それ以前の問題として、Windows 2000 Professional上でのSandra 2002の挙動も気にかかる。Windows 2000は、Hyper-Threadingをサポートしていないが、Sandra 2002はおそらくXeonの設定（CPUID）から判断してHyper-Threadingを有効とみなしているので、ソフトウェアの適用によってこのあたりの挙動は左右されるといっていいかもしれない。つまり、Hyper-ThreadingのEnabled/Disabledの判断は、もっともっと根源的なところで行わなければならないのに、私の使用するThunder i860ではそれができていないのではないか、という可能性の問題である。

さて、Hyper-Threadingの総括をそろそろ行う予定だが、それは次回以降とさせていただくつもりである。（2002/1/25）

【当時を思い起こして】
今では液晶ディスプレイは当たり前だが、当時は性能も今一つで解像度も低く、やたらと高価だったので、ノートPC以外での選択肢は私は想定外だった。この画面写真も今はなき、トリニトロンディスプレイである。ブラウン管タイプは、もうほとんど見なくなったなぁ。

Hyper-Threading──Super πとTMPGEnc同時実行 II（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行」

巻頭言 980　「Hyper-Threading──Super πとTMPGEnc同時実行 II」

Super π（CPU 0, CPU 3）とTMPGEnc（CPU 1, CPU 2）同時実行時のパフォーマンスモニタ

CPU使用率は、同時実行中は75%（Super πにCPU２つを割り当てているが、実行スレッドは１つのため）を示していたが、Super πの処理が終了した後のイメージショットなので画面上は50%となっているが、注目はCPU 0（CPU使用率の履歴の最左）とCPU 3（同、最右）のぶれの大きさである。これまでCPU使用率の履歴をいくつか示してきたが、Super π及びTMPGEncを実行中は、常に振り切れた状態、つまり上で見ると真ん中二つのようになっていた。この激しいぶれは一体、何を示しているのだろうか。
（前回までの続き）

ちなみにSuper πをデフォルトの状態（CPU 0～CPU 3すべてを割り当て）で一つだけ実行した場合、パフォーマンスモニタは次のようになっていた。

Super πで４つのCPUを割り当てた際のCPU使用率遷移

このように、確かにCPU間でSuper πの実行スレッドは分担して行われているものの、さすがに切り替え頻度はTMPGEncを同時実行している時ほど激しいものではない。これらのことから考えられることとしては、TMPGEncのCPU占有度があまりに高いため、Super πがCPUを占有する間もなく、どちらか（CPU 0またはCPU 3）の空き具合、つまり、物理プロセッサに相対するCPU 1またはCPU 2のTMPGEncの実行スレッドのタイミングを見ながら、OS（Windows XP）が切り替えを行っているために、このように実行されるCPUの異動が頻繁に行われると見ていいだろう。

こういった形で処理が並列化しているために、TMPGEncから見れば、本来CPUを占有したいにもかかわらず、OS関与に伴うSuper πの実行スレッドという横槍が入ることから、これまでの実行タイムから若干遅れたものとなったと想定されるというわけである。無論、Super πの側からすれば、TMPGEncがCPUを占有し続けることが多いので、なかなか実行スレッドを処理することができず、こちらも実行タイムが遅れるとなる。

では、同じベンチマークテストをHyper-ThreadingをOFFにした場合はどうなるだろうか。これを行うには、Xeon 2.20GHzからHyper-Threadingテクノロジが使用できないXeon 1.70GHzにプロセッサを変更すれば確実だが、あの面倒な換装作業をしばらくは行いたくないので、擬似的にHyper-ThreadingをOFFにする、/numproc=2オプションを追加することで、物理プロセッサのみを有効にするという方法を採った。
CPUの割り当てはデフォルト（Super π、TMPGEncいずれもCPU 0とCPU 1を割り当て）で、同時実行を行うと………。

─── Freeze…………。

Super πがおおよそ12周目、TMPGEncがおおよそ処理の50％目前といったところで、見事にフリーズである。いやぁ、あっさり落ちるものだと感心しながら、ハードウェアリセットを行い、もう一度、同じ環境で同時実行テストを行うと、

─── Freeze…………。

ははははは……。
当環境だけとは思いたいが、Dual Xeon 2.20GHzでHyper-Threadingを擬似的にOFFにして物理プロセッサ２つのみを有効にし、Super πとTMPGEncを同時実行させると、ハードウェアリセットでなければ復旧不可能なとんでもないフリーズ（ブルーバックが出ないのはもちろん、エラーログすら吐き出されないので、可能性としてはプロセッサ周りが致命傷という恐れが高い）が発生することが確認できた。念のため、もう一度ハードウェアリセットをかけて再々テストを行ったが、やはり結果は同じ。再現性が高いものであるのは疑いない。

それでは、と、再び4CPU状態（/numproc=2をはずす）で同時実行テストを行ったところ、こちらはまったく問題なくテストを終えた。どうやら、 Windows XPそのものの環境にダメージを受けているわけではないので、「Hyper-Threadingを擬似的にOFFにして物理プロセッサ２つのみを有効」にしたことがフリーズの原因であるのは確かだとなる。

というわけで、思いがけないことで時間を食ってしまった。本来なら、Super πとTMPGEncの同時実行テストの話を総括した後、他のテストなりを行う予定でいたのだが、思いがけぬトラブル（仕様？ Bug？）によって、時間が足りなくなってしまったため（Dual XeonマシンはWindows XP起動前までの起動時間が長いのよ）、今回は中途半端であるがこの辺で終わりとしたい。場合によっては、午後あたりに加筆するかもしれないが、例によってあてにならない話なので、かもしかの話ということでご容赦いただきたい。

というわけで続きます。（2002/1/24）

【当時を思い起こして】
このトラブルは、ハードウェアによるものなのか、Hyper-Threading Technologyにからむものなのか、OS側の問題なのか。まったく切り分けることができないまま終わったのが悔やまれるが、使えるICEが自宅になかったので仕方がない。おそらく複合系のような気もするが…。

Hyper-Threadingの有用性──Super πとTMPGEnc同時実行（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「マルチスレッドでのHyper-Threading ── TMPGEnc編 II」

巻頭言 979　「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行」

さて、今回の巻頭言は繰り延べとなっているTMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていくことにしよう。
と、これを行う前に、これまでの簡単な復習──というほどのものではないが、これまでのSuper π及びTMPGEncにおけるテスト結果から導出されるHyper-Threadingの特長についてふれておくことにする。

Super πのようなシングルスレッドアプリケーションでは、基本的に一つのCPUしか使用しないため、CPU 0～CPU 3のいずれに割り当てても、いくつ割り当てようとも結果は同じとなる。そして複数実行した場合は、各々の実行スレッドは独立して実行されることから、スレッド同期を行う必要がないため、実行スレッドの間口が増えるHyper-Threadingの有用性を確認できた。

一方、TMPGEncのようなマルチスレッドアプリケーションでは、基本的にプロセスが支配下に置くことのできるスレッドを一つ一つCPUに割り当てることができるので、スレッドの数だけCPUがあれば、それだけ有効に利用することができる。だが、TMPGEncでは実行スレッドが二つのみであること、スレッド間同期またはプロセッサリソースの占有率の高さ等によって、実質、スレッド毎に物理プロセッサを割り当てなければ意味がないことから、 TMPGEncの複数同時実行だけでなく、単体実行においてもHyper-Threadingの有用性を見出すことはできなかった。

以上の結果を踏まえて、Super πとTMPGEncを同時実行させたとしたら、どういう予想を立てることができるだろうか。単純に考えれば、２つの実行スレッドのプロセッサリソース占有度が高いと目されるTMPGEncが物理プロセッサを乗っ取ったなら、Super πはプロセッサリソースが有効に使うことができず、停止状態に陥ってしまうということが予想できるだろう。これでは、Hyper-Threadingを活かすことはできないとなるのは明白である。

以上のような予想を立てつつ、最初に行う同時実行テストはデフォルトの状態、つまり、CPUの割り当てを特に設定することなく（CPU割り当て上は、CPU 0～CPU 3すべてを当てている）、行った結果から示してみよう。
と、その前に。TMPGEncのテストは従来のものと同様だが、Super πのテストは、通常行う104万桁の計算でなく、52万桁の計算に変えている。変えた理由だが、TMPGEncのテストと実行タイムをなるべく合わせるため、TMPGEncが通常42秒で処理を終了することから、これに近い38秒で処理を終了する52万桁を採用したということである。
では、デフォルトでの同時実行の結果だ。

デフォルト状態（すべてのCPUが割り当て）で、Super πとTMPGEncを同時実行。

いきなり面白い結果となった。Super πについては、初めて52万桁の計算を行ったため、実行タイムが目新しいタイムとなるのはもちろんだが、TMPGEncの実行タイムは54秒という、これまでにまったく見たことのない実行タイムとなった。これまでは、マルチスレッド（２つの実行スレッド）が有効に機能した42秒前後の実行タイムと、実質シングルスレッドのみが有効となった1分25秒前後の実行タイムしかなかった（TMPGEncを複数実行した際に、一方のTMPGEncによってすべてのプロセッサリソースを奪われた場合は実行タイムが大幅に遅れたが、これは例外）。それがこのテストでは54秒とどちらともつかない中途半端なものなのだから、これはじっくりと検証する価値があるというものだろう。

手始めに、物理プロセッサをSuper πとTMPGEncそれぞれに割り当てたらどうなるかを確かめてみよう。シングルスレッドアプリケーションであるSuper πは、プロセッサリソースをTMPGEncに奪われることなく実行できるので、おそらくは単体テストと同様の38秒程度か、あるいはそれよりやや時間がかかる程度であろう。一方、TMPGEncは、物理プロセッサ一つでは実質マルチスレッドを有効に活用できないので、マルチスレッドオプションを無効にした 1分25秒程度と予想できる。
それでは、CPU 0とCPU 2をSuper π、CPU 1とCPU 3をTMPGEncにそれぞれ割り当てた結果をご覧いただこう。

CPU 0とCPU 2にSuper πを、CPU 1とCPU 3にTMPGEncを固定して実行。

何かすいぶんとベタな予想とその結果だと思われるかもしれないが、これが現実である。何度計測しても同じような結果なので、引き続き、Super πをCPU 0だけ、そしてTMPGEncをCPU 1だけに割り当て、残るCPU 1とCPU 2にはこの二つのアプリケーションを割り当てないような形でテストを行ってみた。結果は以下のとおりとなった。

CPU 0にSuper πを、CPU 1にTMPGEncを固定して実行。

シングルスレッドアプリケーションであるSuper πが、CPUの割り当て数を減らしても結果が変わらないのは自明だが、マルチスレッドアプリケーションであるTMPGEncがマルチスレッドオプションを有効にしておきながら、それが機能していないように見えるのは、これまでに指摘しているように物理プロセッサを一つだけしか割り当てていないことによるものだろう。改めて、Hyper-ThreadingがTMPGEncでは有用でないことが確認できたといえるものだが、今はそれに注目しているのではない。TMPGEncの実行タイムが54秒となる組み合わせとしては、物理プロセッサをそれぞれに割り当てたものではないという結果が重要なのである。そうなると、次なる組み合わせは、物理プロセッサをまたがった割り当てでテストを行うことが適当だろう。CPU 0とCPU 3をSuper π、CPU 1とCPU 2をTMPGEncと割り当てた結果は次のとおり。

CPU 0とCPU 3にSuper πを、CPU 1とCPU 2にTMPGEncを固定して実行。

Super πが１秒ほど速くなっているが、誤差の範囲だろう。これが、デフォルトの状態で行った結果と同等であるのはほぼ間違いない。それでは、このテストを実行中のCPU使用率は、どう推移したのだろうか。これも実に興味深い結果を示している。

Super π（CPU 0, CPU 3）とTMPGEnc（CPU 1, CPU 2）同時実行時のパフォーマンスモニタ

CPU使用率は、同時実行中は75%（Super πにCPU２つを割り当てているが、実行スレッドは１つのため）を示していたが、Super πの処理が終了した後のイメージショットなので画面上は50%となっているが、注目はCPU 0（CPU使用率の履歴の最左）とCPU 3（同、最右）のぶれの大きさである。これまでCPU使用率の履歴をいくつか示してきたが、Super π及びTMPGEncを実行中は、常に振り切れた状態、つまり上で見ると真ん中二つのようになっていた。この激しいぶれは一体、何を示しているのだろうか。

───というところで出勤時間が来てしまった。この続きは、また次回以降ということですいません。（2002/1/23）

【当時を思い起こして】
───というところで出勤時間が来てしまった。この台詞で終わることはかなり多かったように思う。だいたい、巻頭言に費やしていた時間は概ね30分。専ら出勤前の朝に書いていたのであった。今は昔。人生を充実させるために、現在はそういう時間を朝取ることはかなわなくなったが、それはそれでよかったと思っている。

マルチスレッドでのHyper-Threading ── TMPGEnc編 II（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「マルチスレッドでのHyper-Threading ── TMPGEnc編」

巻頭言 978　「マルチスレッドでのHyper-Threading ── TMPGEnc編 II」

次回は、TMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていく予定である──としていたが予定を変更させていただくことにする。理由の一つ目は、Intel社のMobileプロセッサに関する話題を一回挟んだこと。これは結果としてそうなったというものだが、もう一つの理由は、TMPGEncによるベンチマークテストを同時に二つ実行した場合どうなるか、ということを確かめるためである。このテストを新たに追加する目的は、 CPUの割り当てが物理プロセッサの割り当て個数の違いだけで、論理プロセッサの個数に依存しないという事実を再確認することが目的である。

Super πでは、同じ実行スレッドが２つであっても、単一物理プロセッサ内の論理プロセッサでスレッドを分け合うことによって、明らかに差が生じていた。だが、 TMPGEncではどのように論理プロセッサを割り当てても、物理プロセッサとしていくつ割り当てられているかによってのみ差が生じた。これをよりはっきりさせるには、二つのTMPGEncを同時実行させ、それぞれに物理プロセッサを一つずつ割り当てる（CPU 0とCPU 2に一つ目のTMPGEnc、CPU 1とCPU 3に二つ目のTMPGEnc）ものと、それぞれに物理プロセッサを二つ割り当てる（CPU 0とCPU 1に一つ目のTMPGEnc、CPU 2とCPU 3に二つ目のTMPGEnc）ものを比較することである。それでは、その結果を以下に示そう。

CPU 0, CPU 2に一つ目のTMPGEncを、CPU 1, CPU 3に二つ目のTMPGEncを割当て実行

CPU 0, CPU 1に一つ目のTMPGEncを、CPU 2, CPU 3に二つ目のTMPGEncを割当て実行

テスト内容及び方法は、巻頭言976を参照いただきたいが、なかなか興味深い結果となっている。その差はわずかに１秒だが、これは測定誤差の範疇に収めても支障はないものだろう。つまり、物理プロセッサを意識して割り当ててもそうでなくても、どちらも結果は変わらないということである。これだけでも驚くべき結果だが、それ以上に興味深いのは、マルチスレッドオプションを有効にしないテストとほぼ同じ実行タイムとなっているということだ。これはどういうことだろう。

以前にも議論したように、TMPGEnc 2.02でマルチスレッドを有効にすると、処理を実行するスレッドは二つになるが、この実行スレッドはプロセッサリソースを使い切るか、あるいはスレッド間同期によって、事実上一つのスレッドが一つの物理プロセッサを完全に占有してしまうと考えられる（厳密に言えばそうはならないが、アプリケーション間同士ではそう見えるということ）。このため、物理プロセッサが一つしかない場合（強制的に一つしか割当てられていないことも同義）、マルチスレッドは有効に機能せず、結果としてシングルスレッドと同じになってしまうわけである。

TMPGEncを二つ同時に実行するということは、言い換えれば４つの実行スレッドのうち、２つの実行スレッドだけが意味を持つので、残る２つはプロセッサリソースを占有することができず、まったく実行されることがない（ほとんど実行されることがない）ということである。だからこそ、マルチスレッドであってもシングルスレッドと同じ結果となるわけだが、ここで一つ疑問が生ずる。それは、CPU 0とCPU2、CPU 1とCPU 3というように、明確に物理プロセッサを一つずつTMPGEncに与えれば問題はないが、CPU 0とCPU 1、CPU 2とCPU 3というように、物理プロセッサをまたいで割り当てを行うと、物理プロセッサを占有するスレッドが両方とも一方のTMPGEncになった場合、物理プロセッサが割り当てられないTMPGEncは処理が停止してしまうのではないかという疑問である。

このことを確認するために、CPU 0とCPU 1、CPU 2とCPU 3という割り当てで、何度かテストを繰り返すと、４度目のテストでは、一方のTMPGEncの処理が完全に停止してしまい、処理が継続している TMPGEncが終了して、ようやくもう一方のTMPGEncの停止状態が解除されることで、実行タイムが大きく乖離するという現象が発生した。このように予想通りの結果を見たことから、先ほどの推論はまったくの的外れではないということと、また、OS（Windows XP）が論理プロセッサの割り当てに関して、物理プロセッサとの関係を意識していないで割り当てを行っていることも、結果として確かめられたとなるだろう。この点が、まさにHyper-Threadingのアキレス腱というわけである。

さて、次回の予定だが、今度こそSuper πとTMPGEncの同時実行によるHyper-Threadingの検証を行うつもりである。（2002/1/22）

マルチスレッドでのHyper-Threading ── TMPGEnc編（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Windows XP Home EditionでHyper-Threadingは有効になるか？」

巻頭言 976　「マルチスレッドでのHyper-Threading ── TMPGEnc編」

これまで、Hyper-Threadingテクノロジの検証を主にSuper πにて行ってきたが、今回は定評のあるTMPGEnc 2.02を用いて、マルチスレッドアプリケーションプログラムにおけるHyper-Threadingテクノロジの有用性を検討してみたい。

ただ、TMPGEncでテストを行うにしても、なかなか客観性を持たせることが難しいので、TMPGEncのベンチマークテストとして公開されているLightBench（華）（TMPGEnc De Bench !!さんのWebサイトを参照）を利用させていただくことにした。
（大雑把に言ってしまえば、1分ほどの映像データをVideo CD形式にエンコードするテスト。）

まずは、LightBench（華）の設定を行い、テストを始める前にTMPGEnc 2.02の環境設定（CPU）を次のように変更した。

TMPGEnc 2.02のCPUに関する設定

デフォルトでは、「マルチスレッド使用」とある部分がチェックされていない（＝マルチスレッドを使用しない）となっているが、これをチェックし、「マルチスレッドの設定」では上のように「パイプライン化する」と「動き検索をパイプライン化する」にチェックを入れた。

この設定に変更して、そのまま実行するとテスト時間は42秒という結果になった。
引き続き、「マルチスレッド使用」のチェックをはずして（デフォルトに戻す）実行したところ、テスト時間は1分25秒となり、マルチスレッドの効果を確認できた。

それでは、Hyper-Threadingの有用性を確かめるべく、CPUの割り当てを変更することにしよう。回りくどい説明は抜きにして結果を表にすれば、次のような結果となった。

TMPGEnc 2.02によるLightBench（華）のCPU割り当て別の結果
（Windows XP Professionalで、上にある条件で「マルチスレッド使用」している。
なお、タスクマネージャのパフォーマンスモニタを表示状態にしてある。）

CPUの組み合わせはまだまだあるが、ここまで行えば傾向は掴めるだろう。なお、このテストで若干実行タイムが遅くなっているのは、タスクマネージャに含まれるパフォーマンスモニタを常時表示していたためである。CPU使用率の様子を確認するため、表示させていたのだが、実に面白味のない結果となってしまった。

最初に、CPUを一つだけ割り当てた結果についてだが、これは「マルチスレッド使用」という設定をOFFにしたテストと同等の結果であることが分かる。つまり、自明のことではあるが、与えられたCPUが一つではマルチスレッド化する効果が表れないということである。

一方、CPUを複数割り当てた場合は、これは物理プロセッサが一つであった場合と二つであった場合では、結果は大きく異なるものとなる。とは言っても、物理プロセッサが一つの割り当てでは、「マルチスレッド使用」という設定をOFFにしたテストと同等の結果であり、二つの場合は「マルチスレッド使用」と同じである。おそらく、TMPGEnc 2.02は、実行スレッドが２つ（あるいは演算部分が２つと、もう１つメインスレッドがあるかもしれない）であり、一つのスレッドがほぼプロセッサリソースを使い切ってしまうか、さもなければスレッド間での同期等により、このような結果となるのだろう。

このことからわかるように、TMPGEnc 2.02を一つだけ実行した場合は、マルチスレッドを有効にしてもHyper-Threadingの効果はほとんど表れないということになる。これが実行スレッドが３つ以上であれば、また違う結果となるかもしれないが、現状においてはそういうことである。

次回は、TMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていく予定である。（2002/1/21）

【当時を思い起こして】
この頃は、動画のエンコードを行うのも一苦労であった。そのため、パフォーマンスの高いPCが必須であったが、今ではそこそこの価格のPCでも、あまり困るようなシーンはなくなっている。それでも、解像度の細かいものにはそれなりのパフォーマンスが必要であり、まだまだパフォーマンスを求める用途の一つだろう。

Windows XP Home EditionでHyper-Threadingは有効になるか？（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Dual Xeon 2.20GHz ベンチマーク編 III」

巻頭言 974　「Windows XP Home EditionでHyper-Threadingは有効になるか？」

今回の巻頭言は、Hyper-Threadingの有用性について検討する予定としていたが、まだまだベンチマークテストとして追加すべきものをいくつか考えたので（検討を行う過程で、新たなテスト方法を追加すべきという考えに達したため）、これを行ってからHyper-Threadingテクノロジの有用性については考察していきたい。

そこで、時間のかかるベンチマークテストを行うには、今回の巻頭言には間に合わないことから、特別企画（別名、穴埋めあるいは埋め草とも言う）として取り上げるものは、表題のとおり、「Windows XP Home EditionでHyper-Threadingは有効になるか？」ということについてである。

Windows XPの二つのEdition。Home Editionは、シングルプロセッサのみにライセンスされるものであり、もう一方のProfessional Editionは、シングル及びデュアルプロセッサにライセンスされるとなっている。Windows XP Professionalの前バージョンとなるWindows 2000 Professionalや、さらにその前のWindows NT 4.0 Workstationも、デュアルプロセッサまでというライセンス条件に違いはない。

Windows XP ProfessionalやWindows 2000 Professional、Windows NT 4.0 Workstationは、OSインストール時にハードウェア環境を確認し、シングルプロセッサ環境であれば、Uni Processor Kernelをセットアップし、デュアルプロセッサ環境であれば、Multi Processor Kernelがセットアップされることは、これらのOSをインストールされた方なら自明であろう。

しかし、Hyper-ThreadingテクノロジをサポートしたWindows XPでは、たとえシングルプロセッサ環境にあっても、Multi Processor Kernelが必要になる。Hyper-ThreadingテクノロジをサポートしていないWindows 2000以前のOSであれば、もちろんUni Processor Kernelで問題はないが（物理プロセッサ数＝論理プロセッサ数のため）、一粒で二度おいしい……ではなく、一つのプロセッサであっても二つと認識する Windows XPなのだから、Uni Processor Kernelではそれを活かすことができなくなってしまうからである。

Windows XP Home Editionは、シングルプロセッサのみのライセンスではあるが、これは物理プロセッサのことであるのはいうまでもない。なぜなら、デュアルプロセッサまでのライセンスとされているWindows XP Professionalで４つのプロセッサを認識・実行しているのだから、Microsoft社がこのあたりの制限を存置したままリリースしたとは考えにくいという理由からである。これを確認するには、4-way以上のPCにWindows XP Professionalをインストールし、物理的に４つのプロセッサを有効にできるか否かで行えるが、残念ながら自宅にそんな剛毅なマシンはないので確認できない。なので、確実にそうだと断言できるものではないが、そうだと推測して話を進めることにする。

なぜ、こういうことにこだわるかというと、一般的にシングルプロセッサのみをサポートするということは、Uni Processor Kernelだけでいいはずである。だが、Hyper-Threadingテクノロジの登場によって、シングルプロセッサなのに論理プロセッサとしてはデュアルプロセッサと同等となるということは、つまり、Home EditionでもMulti Processor Kernelが要求されるからである。このあたりのことが既に製品としてサポートされているのかを確認するには、とにもかくにもWindows XP Home EditionをDual Xeon 2.20GHzマシンにクリーンインストールしてみるのが一番である。

ということで、早速パーティションを一つ作り、Windows XP Home Editionをクリーンインストールを行った。Windows XP Professionalのクリーンインストールはこれまで何度も、いや何十度も行ってきているが、Home Editionの方は、実質二度目くらいである。とは言いつつも、Professional EditionとHome Editionのクリーンインストールにこれといった違いはないに等しいので、Home Editionだからと特筆すべきものもなく、無事にクリーンインストールが終了した。さて、早速確認すべきは、Uni Processor Kernelなのか、Multi Processor Kernelなのか……。

イベントビューアのシステムログ情報からわかるMulti Processor Kernelサポート

イベントビューア（システム）情報よりログを確認してみると、上記のとおり、「Multiprocessor Free」の文字が…。本来、シングルプロセッサだけをサポートするのであれば、「Uniprocessor Free」となるはずが、そうなってはいない。こうなれば、「Ctrl＋Alt＋Delete」でタスクマネージャを呼び出し、パフォーマンスモニタで CPU使用率を確認するしかない。でその結果は…、

Windows XP Home Editionにおけるパフォーマンスモニタの結果

しっかりと２つのCPUとしてサポートされている。そう、Windows XP Home Editionは、シングルプロセッサのみのライセンスでありながら、デュアルプロセッササポートを実現しているのである。Hyper- Threadingテクノロジをサポートしているとするなら、こういう結果となるのは明らかではあるが、シングルプロセッサとしてリリースされるものの中に、Hyper-Threadingテクノロジをサポートしているものは一つもないのが現状であるが、OSの方では「Ready!」状態となっているわけである。
（もっとも、Windows XPのリリース日を考えれば、この時、Hyper-Threadingテクノロジをサポートしたプロセッサすらリリースされていないのだから→正確に言えば現在でもそうだが…、驚くに値しないとも言える。だが、そうなると、Home EditionとProfessional Editionの敷居がまた一つなくなったとなるだろう。）

これは、デバイスマネージャを見ると、よりはっきりと確認できるものである。

Windows XP Home Editionにおけるデバイスマネージャの結果

「ACPIマルチプロセッサ PC」とあるが、もちろんハードウェア上ではそうなっているものの、Windows XP Home Editionでは、物理プロセッサを一つのみサポートしているだけであるので、これがHyper-Threadingテクノロジをサポートしていないプロセッサ（例えばDual Xeon 1.70GHz）ではこうはならない。「ACPI (Advanced Configuration and Power Interface) PC」などという表記に変わり、シングルプロセッサを対象としたシステムになるだけの話である。

ところが、Hyper-Threadingテクノロジをサポートしたプロセッサであれば、物理的に一つのプロセッサであっても論理的には二つのプロセッサとなるので、デバイスマネージャではこれをマルチプロセッサPCとみなすようになる。これはなかなか凄いことだと思うが、デバイスマネージャの表示に一部疑問が残るものもある。

それは、Windows XP Home Editionのデバイスマネージャにもプロセッサが二つ出ていることである。デュアルプロセッサをサポートし、４つのCPUが実現されている Windows XP Professionalのデバイスマネージャでも、以前に示したようにこうなっているからだ。

Windows XP Professional Edition（4CPU認識）におけるデバイスマネージャの結果

このように、まったく同じなのである。これは、物理的に接続されているプロセッサのみを示すと考えていたのだが、Home Editionの結果も同じものだとすると、考え方を変えなくてはならないのかもしれない。それとも、Home Editionでも、実は物理的に２つのプロセッサを認識しているのだろうか。物理的に一つなのか二つなのか、これを確認するためには、前回巻頭言で示したSuper πによるベンチマークテストを行ってみればわかるだろう。CPU 0とCPU 1にそれぞれSuper πの実行スレッドを２つずつ持たせ、計４つを同時実行し、結果を比較すればはっきりする。早速テストを行ってみよう。

上は、Super πを４つ同時実行させているときのパフォーマンスモニタの様子であるが、CPU 0、CPU 1いずれも使用率は最高となり、全体としての使用率も100%に届いていた。では、結果である。

CPU 0とCPU 1に二つずつ実行スレッドを割り当てた場合（Windows XP Home Edition）

なお、Windows XP Professionalで、Hyper-ThreadingをOFF（boot.iniで、/numproc=2を指定）にしたデュアルプロセッサ環境では、以前にも示したように次のとおりとなっている。

CPU 0とCPU 1に二つずつ実行スレッドを割り当てた場合（Windows XP Professionalで
Hyper-ThreadingをOFF）

見かけ上は同じデュアルプロセッサだが、やはり物理プロセッサ二つと論理プロセッサ二つでは勝負にならない。このことから明らかなように、Windows XP Home Editionでは物理プロセッサのサポートは一つであることが確認できたが、このHome Editionの結果は、Professional Editionの４CPUサポート状態で、CPU 0とCPU 2に割り当てた結果と酷似していることも確認できる。

CPU 0とCPU 2に二つずつ実行スレッドを割り当てた場合（Windows XP Professionalで
Hyper-ThreadingをON）

つまり、先のHome Editionの結果に対応物理プロセッサを表記すれば、

CPU 0とCPU 1に二つずつ実行スレッドを割り当てた場合（Windows XP Home Edition）

のようになるので、これは、4CPU時におけるCPU 0とCPU 2への割り当てと同じように、物理プロセッサに４つの実行スレッドを割り当てているのと同様だからといえるだろう。Home EditionとProfessional Editionのわずかながらの差は、物理プロセッサがもう一つあるかないかの差異と思われる。

閑話休題的に話を進める予定だったのだが、思わぬ結果（いや、予想通りか）となったため、それなりのボリュームとなってしまった。というわけで、 Windows XP Home Editionにも最初からマルチプロセッサ対応が確認できたことを示したことで、今回の巻頭言は終わりとしよう。明日は、どうしようか……。（2002/1/19）

【当時を思い起こして】
Windows XP Home Editionを確認する作業によって、よりHyper-Threading Technologyへの理解が深まると同時に、Professional Editionとの違いがどのように作られたのかを垣間見ることができた。しかし、この頃はよくOSのインストール作業を繰り返し行っていたものだと感心する（苦笑）。

Dual Xeon 2.20GHz ベンチマーク編 III（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Dual Xeon 2.20GHz ベンチマーク編 II」

巻頭言 973　「Dual Xeon 2.20GHz ベンチマーク編 III」

驚いたことに物理的には２つのプロセッサと変わらないものの、Hyper-Threadingが有効でOS上では４つのプロセッサとして扱われているものと比較すると、実に45秒の短縮、率にして三割以上の性能アップとなったのである。
（前回までの続き）

これだけ見れば、確かにHyper-Threadingの効果は確認できる。だが、私にとって気になるのは、１つの物理プロセッサ内にある２つの論理プロセッサにスレッドが割り当てられた場合、どの程度パフォーマンスに影響が出るのかということがある。物理プロセッサと論理プロセッサの関係をもう一度示すと次のようになっている。

確かにこれで誤りはないのだが、いかんせん前回の巻頭言ではこのあたりがさっぱり意味不明というご意見を頂戴しているので、次回以降に予定している Hyper-Threadingテクノロジの解説まで待たず、ごくごく簡単にではあるが、Hyper-Threadingテクノロジについて、比喩を交えて説明しておこう。

上に、Intel社の「Introduction to Hyper-Threading Technology」というドキュメントを参考にしたHyper-Threadingテクノロジの概念図を作成してみたので、これを見ながら話を進めよう。

図中の上に示したのは、２つのXeon 1.70GHzで構成されたシステムのプロセッサ周り、下は、２つのXeon 2.20GHzで構成されたシステムのプロセッサ周りである。大きな違いは、プロセッサ内のAS（IA-32 Architectual State）の個数が１つであるか２つであるかのみであり、これがHyper-Threadingテクノロジの肝である。IA-32 Architectual Stateとは何かというと、比喩的に言ってしまえば受付窓口のようなものである。

従来のプロセッサには命令の受け入れ窓口が一つしかなかった。これが二つに増えたことで、命令の受け入れ窓口をOSから見てプロセッサに見立てるというものが、論理（仮想）プロセッサである。OSから見れば、プロセッサとは命令受け入れ口に過ぎないのだから、それが本当に（物理的に）一つなのか二つなのかというのはまったくといっていいほど関係がない。

喩えて言うなら、今までは一つの店舗に一つのレジでやっていたが、品数が少なく簡単なものばかりであれば、店舗に働く従業員すべてに仕事が行き渡っていた。ところが、品数が増え、複雑な注文や注文がキャンセルされるようなことが出てくると、一つのレジでは仕事を処理しきれず、そのためにレジの仕事率を上げるなどしたが、今度はレジが誤るようになって来てしまい、店舗に働く従業員が暇をもてあますようになる等、処理能力を上げても非効率になり、とうとうライバル店の売上高に溝をあけられてしまった。それを改善するには、店舗の従業員を増やしたり、レジの回転率をこれ以上上げるというのは困難なので、今まで伝統的にレジを１つだったものを２つに増やし、遊んでいる従業員を少しでも働かせて効率をよくしようという方法を採用したのである。

喩え話で言えば、以上のようなものとなるだろうか。要するに、プロセッサの資源を増やして処理能力を上げるのではなく、プロセッサの資源をさらに有効活用して処理能力を上げようというアプローチなのである。

さて、喩え話が長くなってしまった。話を元に戻そう。
CPU 0とCPU 1を利用する場合と、CPU 0とCPU 2を利用する場合とでは、実質、物理プロセッサ２つと物理プロセッサ内の論理プロセッサ２つとの比較になるということである。上図からも明らかであるが、この両者が同じ結果を生むとは考えにくい。これを確認するため、これまでのテストと同様、Super πを用いて次のようなベンチマークテストを行ってみた。

これまでとの比較をする意味から、同時に実行するSuper πの数を４つと同じに揃え、２つずつ個別のCPUにスレッドを実行させるようにする。一つは、CPU 0とCPU 1にSuper πのスレッドを２つずつ持たせ、もう一つは、CPU 0とCPU 2に同じくSuper πのスレッドを２つずつ持たせることで違いを確認できるだろう。以下がその結果である。

最初は、CPU 0とCPU 1の組み合わせの結果である。この組み合わせは、物理プロセッサ２つであるので、前回テストしたHyper-Threadingを無効にした従来の Xeonと同じようなものといえるだろう。実行タイムは、CPU 0の側が2分55秒と2分56秒。CPU 1の側が両方とも2分56秒という結果になった。これは、プロセッサ数を２と制限（＝Hyper-Threadingを無効）したものと比較すると、わずかながらであるが実行時間が３～５秒程度は短くなっている。これは、CPU使用率が51%と50%を超えていることからわかるように、Super π以外の実行スレッドがCPU 2やCPU 3で処理されることによるパフォーマンスアップである。

続いて最も興味深いテストとなるであろう、CPU 0とCPU 2の組み合わせの結果である。この組み合わせは、１つの物理プロセッサ内の２つの論理プロセッサで処理することになるので、Hyper- Threadingの弱点となり得るスレッドスケジューリングについての考察に役立つものとなるだろう。

パフォーマンスモニタの結果は、特に変わるものはないが、実行タイムは興味深い結果となった。CPU 0の側が4分8秒と4分11秒、CPU 2の側が4分7秒と4分10秒。面白いことに、常に同じCPUで実行する一方のスレッドの終了時間が長くなるのである。Super πの終了時間で計測すると、最後の方で一方のスレッドが終了するタイミングで処理が加速されてしまうため、４つの処理が並行して行われている19回目のループ終了時間で比較すると、その差はさらに強調されるものとなる。CPU 0の側は3分57秒と4分4秒、CPU 2の側は3分56秒と4分4秒。その差は実に７～８秒の開きを示したのである。

ちなみに４つのSuper πをすべてCPU 0に割り当てた結果は、実行タイムで5分33秒、5分36秒、5分37秒、5分37秒となっており、19回目のループ終了時間を見ると、４つともほぼ同じ時間であることから、明らかに違いがあることが確認できる。
ここで以上までの違いを明確にするため、表にして確認してみよう。

CPU 0～CPU 3に一つずつ実行スレッドを割り当てた場合

CPU 0とCPU 1に二つずつ実行スレッドを割り当てた場合

CPU 0とCPU 1に二つずつ実行スレッドを割り当てた場合（Hyper-ThreadingをOFF）

物理的にはSuper πを２つずつ割り当てた結果だが、それぞれまったく異なる結果を示している。うまくスレッドが割り当てられれば、従来と比較して30%以上の性能アップと言うIntel社のアナウンスは確かだといえるが、ベストの場合であるのはいうまでもない。これが物理プロセッサを基準とするのではなく、論理プロセッサを基準に採れば、CPU 0とCPU 2の組み合わせもある。

CPU 0とCPU 2に二つずつ実行スレッドを割り当てた場合

論理的に見れば２つのプロセッサに分散されているものの、物理的に見れば１つのプロセッサで実行されるこの組み合わせでは、先のいずれにも劣る結果となってしまう。もっとも、実際の局面においては実行スレッドとプロセッサを固定することはしないので（以前、Super πを一つだけ実行した例で示したように、単一スレッドであっても実行プロセッサは変化することが多い）、OSのスレッドスケジューリングが間抜けでない限りは、このような最悪な状況を迎えることはきわめて少ないということができるだろう。なお、同じ１つの物理プロセッサに割り当てられるものでも、論理プロセッサが１つに集中してしまうと、

CPU 0に４つの実行スレッドを割り当てた場合

となるように、Hyper-Threadingの効果が発揮されていないわけではないことが確認できる。まさにこのことが、IA-32 Architectual State増設の効果（＋OSのサポート）だといえよう。
さて、次回の予定だが、以上までの結果を踏まえてHyper-Threadingの有用性について、考えていく予定である。（2002/1/18）

【当時を思い起こして】
この時は、Super πをそれこそ何度行ったか。そして、何度も再起動を行ったことを思い出す。このPCはメモリチェックにやたらと時間のかかるものだったので、再起動作業をするだけで、それこそ何分も待たされるのだ（イメージ）。だが、そういった作業が苦とならなかったのは、Hyper-Threading Technologyの実態が見え隠れするような結果を見たからにほかならない。

Dual Xeon 2.20GHz ベンチマーク編 II（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Dual Xeon 2.20GHz ベンチマーク編 I」

巻頭言 972　「Dual Xeon 2.20GHz ベンチマーク編 II」

さて、前回予告どおり、Super π（以下、特に断りがなければ104万桁のテスト）を使いながら、Hyper-Threadingテクノロジの有効性を検証する。まず始めに、 Hyper-Threadingが有効で、他には特に何も設定しない状態で実行した結果から示していこう。

先に注意事項から述べておこう。Super πのベンチマークテストを行うにあたり、頻繁に設定を変える予定なので、その都度リセットを行う際、少しでも起動時間を節約するために通常2GBのメモリを半分の1GBに減らしている（具体的には８本のRIMMを４本に減らしている）。

さて、上がその結果であるが、Super πはいわゆるx87浮動小数点演算命令を利用しているので、Pentium IIIと比べてもFPU性能低下が著しいため、Athlonとはまったく勝負にならない（このあたりの理屈を抜きに、Super πでAthlonは速いと言うのは甚だわかっていないとしか言いようがない）のだが、2.20GHzというクロックでこの数字を叩き出している。Xeon 1.70GHzの時には、1分51秒だったので1分23秒ということは約28秒の短縮となる。約1.34倍の向上と計算上はなるので、クロック比よりもやや上回っているとなるだろう。

なお、Super πは、シングルスレッドアプリケーションプログラムなので、複数のCPUを割り当ててもまったく効果は変わらないが、OS（Windows XP）によって、デフォルトでは次のようにCPUは割り当てられている。

CPU 0、CPU 1、CPU 2、CPU 3と４つのCPUが割り当てられているが、無論、物理的にプロセッサ数は２つなので、残る２つは仮想（論理）プロセッサとなるが、この４つのCPUの関係は次のようになっている。

ただし、このように割り当てられてはいるが、CPU 0とCPU 2の間において、どちらかが物理プロセッサでもう一方が仮想（論理）プロセッサとなっているのではなく、一つのプロセッサの中に二つの処理可能状態（IA-32 Architectual State）を持つというものなので、両者間に優先順位や優位性を持つといったものはない。

さて、先にもふれたようにSuper πは、シングルスレッドアプリケーションプログラムであるので、デフォルトで４つのCPUを割り当てられていても、実際に使用されるCPUは１つである。ただし、CPU 0～CPU 3のいずれかを使うかは、OSによって委ねられている。タスクマネージャのパフォーマンスモニタに表示されるCPU使用率で、そのことを確認してみよう。

４つのCPUがあるため、１つあたりの使用率は最大で25%。つまり、スレッドが１つのSuper πのみがアクティブで実行されている状態では、CPU使用率の最大値は25%までとなる。４つのCPUでSuper πが実行されていることがモニタから読み取ることができるが、常に実行されているのは１つのCPUとなっていることがわかるだろう。

このように、OSがCPUの割り当てを行っているのだが、上の「プロセッサの関係」というもので、実行するCPUを特定してしまえば、OSはCPUのスケジューリングを行わず、常に指定されたCPUのみで実行するようになる。そこで、CPU 0～CPU 3に違いがあるかを確認するために、それぞれ一つだけSuper πの実行をするように制限したテストを行ってみよう。最初は、CPU 0のみにSuper πを割り当てた結果である（「プロセッサの関係」で、CPU 0のみにチェックを入れた場合）。

結果は1分25秒。パフォーマンスモニタを常時表示したまま計測している（以下、すべてのSuper πのベンチマーク結果は、パフォーマンスモニタ常時表示状態で実施）ため、約２秒ほど遅い結果となっているが、CPU使用率から自明のように、４つの CPUを割り当てた状態と基本的に変わらないものである。この後、引き続き、CPU 1～CPU 3についてそれぞれ行ってみたが、見事に結果は横並びの1分25秒となった。シングルスレッドにおいては、CPU 0～CPU 3の４つのCPUいずれもが等価であるということが確認できたわけである。

続いてのテストは、４つのCPUが同時に有効になるかを確認するため、Super πを４つ実行して、CPU 0～CPU 3のすべてに一つずつのSuper πを実行させることにした。もちろん、Super πはπの演算結果を書き出すため、それぞれ異なるフォルダに４つSuper πを用意して、それぞれ実行させなければならない点に注意が必要である。で、結果は次のとおりとなった。

ちょっと画面コピーをするタイミングが遅くなってしまったため、CPU使用率が0%の状態となってしまっているが、グラフをご覧いただければ明らかなように、４つのCPUがすべて使用されたため、実行中は100%となっていた。で、肝心の実行タイムは、４つとも、2分13秒から2分16秒の間である。時間にややばらつきがあるのは、４つのSuper πを手作業で順次実行したため、タイムラグが生ずることによる。当然、最初に実行したものはプロセスが一つしかないため、わずかだが演算効率が上がること。そして、終了が遅くなるものも最後はプロセスが一つになるので、これもわずかに演算効率が上がるために生ずるばらつきである。よって、この結果でも CPU 0～CPU 3は、いずれも等価であるということができるだろう。

ここで一旦、４つのCPUによるSuper πの結果は置いておいて、boot.iniに「/numproc=2」オプションを追加してCPUを２つに制限した状態で再起動した（＝Hyper- Threadingを結果的にOFFにした）環境で、Super πを４つ実行させた結果を示しておこう。CPUが２つなので、１つのCPUには２つのSuper πを割り当てることになるが、物理的なプロセッサ単位としてはまったく同じであるので、Hyper-Threadingの有効性がどれほどのものかを垣間見ることができるはずである。では、その結果だ。

CPUの実行スレッドが１つだろうと２つだろうと、使用率そのものが変わるわけではない（使用率から仕事量が算出できないから）ので、このように２CPU か４CPUかの違いにしか見えないが、かかった時間は同じではなかった。実行タイムは、2分58秒から3分1秒の間であった。タイムにばらつきがあるのは先に示した理由と同じだが、驚いたことに物理的には２つのプロセッサと変わらないものの、Hyper-Threadingが有効でOS上では４つのプロセッサとして扱われているものと比較すると、実に45秒の短縮、率にして三割以上の性能アップとなったのである。

この項、つづく。（2002/1/17）

【当時を思い起こして】
ずいぶんとイメージ（画像）が切れっ端というか、余計なものを排除しているかが確認できるが、ファイルサイズを少しでも軽減しようという涙ぐましい配慮である。最近はほとんど気にすることはないといいつつも、さすがにデジカメのJPEGデータを何もせずにアップする気にはなれない（苦笑）。

Dual Xeon 2.20GHz ベンチマーク編 I（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Dual Xeon 2.20GHz インストール編」

巻頭言 971　「Dual Xeon 2.20GHz ベンチマーク編 I」

BIOS設定で、Hyper-Threadingテクノロジを使用しない（Jackson TechnologyをDisabled）にしておきながら、WCPUID 3.0fやIntel Processor Frequency ID Utility 4.00.20020109では４つのプロセッサとなっているが、これはタスクマネージャ内のパフォーマンスモニタでも同様であった。

このパフォーマンスモニタでのCPU使用率の変動も、４つがそれぞれ固有に動いており、これだけ見れば４つのプロセッサを搭載したシステムにしか見えない。が、いうまでもなく実際には、Xeon 2.20GHzは２つしかない。これがHyper-Threadingテクノロジをサポートした威力なのかと確認できるが、BIOSでDisableにしていながらこれでは、何のためのBIOS設定だろうかとなる。ちなみに、BIOS設定でHyper-Threadingを利用する設定にしても同じ結果（逆に異なる結果となる方がまずいが…）となるので、BIOSでの設定は単純に起動画面でBIOSのサポートプロセッサ数が２つなのか４つなのかという違いしかないようである。
（BIOS設定をJackson TechnologyをDisabledにした状態で、Windows XP Professionalをクリーンインストールしても、最初から４プロセッサとしてWindows XPでは認識されることは確認済みである。おそらく、Windows XP Professionalでは、BIOSの設定とは関係なく、CPUIDの28ビット目が立っていて（Hyper-Threadingが有効）、かつ、 EBXレジスタの16から23ビットで構成する8-bit値が十進表記で２（仮想プロセッサの個数で、現在はHyper-Threadingが有効の場合、１または２しかない）であれば、Hyper-Threadingテクノロジがサポートされていると判断しているのだろう。ちなみに WillametteやNorthwoodでは、Hyper-Threadingフラグは有効だが、仮想プロセッサ数は１となっている。）

ということがわかってしまえば、Windows XP ProfessionalでHyper-Threadingテクノロジを無効にするには、BIOS設定で行うのではなく、プロセッサ数を制限することで対応するしかない。その方法は、Windows XPが起動時に参照するboot.iniというファイルに記載される内容を書き換えるものである。
一般的に下記のようになっているところ（環境などによって当然違いがある）を

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

オプションとして「/numproc=2」（数字はプロセッサ数）と追加すればよいだけである（無論、再起動が必要）。

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /numproc=2

これで、Hyper-Threadingテクノロジは、結果としてOFFにできる。懸念されることとしては、２つのプロセッサということで、１つのプロセッサの中の仮想（論理）プロセッサが２つ有効になるというおそれがあるが、あとでふれるようにベンチマークテストの結果やSandraの情報等から、本物のプロセッサとして２つが有効となっているはずである。
（Windows XPがHyper-Threadingを有効にするのは、boot.iniを参照する後であるので、boot.ini参照時にプロセッサ数が２と限定されれば、当然物理プロセッサが２つあるのでこれがそのまま割り当てられることになる。ちなみに、Xeonが一つしか搭載されていない状態でプロセッサ数が２とされていれば、２つ目のプロセッサとしてHyper-Threadingにおける仮想プロセッサが有効にされるだろう。）

さて、このあたりでインストール話は中断して、Dual Xeon 2.20GHzとDual Xeon 1.70GHzとの比較をSiSoftware Sandra 2002.1.8.59で行ってみるとしよう。違いはプロセッサのみで、他はまったく変えていない。まずは、CPU Arithmetric Benchmarkである。

Sandra 2002.1.8.59 CPU Arithmetric Benchmarkの結果（Dual Xeon 2.20GHz）

Sandra 2002.1.8.59 CPU Arithmetric Benchmarkの結果（Dual Xeon 1.70GHz）

見方によっては、この比較は妥当なものとは言えない。なぜなら、Hyper-Threadingテクノロジが有効になっているXeon 2.20GHzのテストではスレッドが４つで、そうでないXeon 1.70GHzのテストではスレッドが２つだからである。だが、重要なのは、物理プロセッサ２つで同時実行がサポートできるスレッド数がいくつであるかという点であるので、むしろプロセッサリソースを有効に引き出すという点からは妥当であるとなるだろう。

結果はご覧のように、Dhrystone ALUではXeon 2.20GHzが10009MIPSに対して、Xeon 1.70GHzが6415MIPSと約1.56倍となっている。もう一方のWhetstoneは、FPUでXeon 2.20GHzが3537MFLOPSに対して、Xeon 1.70GHzが1759MFLOPSと約2.01倍。iSSE2とより優位な比較では、Xeon 2.20GHzが8616MFLOPSに対して、Xeon 1.70GHzが4131MFLOPSと約2.09倍。スレッド数の違いはあれど、ここまでのパフォーマンスブーストは凄まじいの一語に尽きる。

それでは引き続き、CPU Multi-Media Benchmarkの比較である。

Sandra 2002.1.8.59 CPU Multi-Media Benchmarkの結果（Dual Xeon 2.20GHz）

Sandra 2002.1.8.59 CPU Multi-Media Benchmarkの結果（Dual Xeon 1.70GHz）

このベンチマークテストもCPU Arithmetricと同じく、スレッド数に違いがある。とはいえ、これもあとでふれるが、単純にスレッド数を増やせば処理効率が上がるかといえば、必ずしもそうではない。要は、数多くのスレッドをどれだけ効率よくスケジューリングして実行できるかという、OS側の問題も考慮に入れておく必要がある。

というのがSandra 2002におけるプロセッサ関連のベンチマークテストの結果である。次回は、Super πを使いながら、Hyper-Threadingテクノロジの有効性を検証する予定である。この項、つづく。（2002/1/16）

【当時を思い起こして】
いよいよベンチマークテストを敢行したが、Hyper-Threading Technologyの実態を掴みながらの作業は、どのような結果を生むのか予想がつかなかったので、危険な意味ではなく未知への探求という意味においてスリリングであったことを思い出す。単純にクロックアップしただけではないという違いを見いだすには、どうすればいいのか？という試行錯誤も、懐かしい思い出だ。

Dual Xeon 2.20GHz インストール編（XWIN2WP BKNUM）

【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「Xeon 2.20GHz導入 はじめの一歩」

巻頭言 969　「Dual Xeon 2.20GHz インストール編」

今日は成人の日である。国民の休日に関する法律改正前までは、1月15日と固定されていたものが、15日のもっとも近い月曜日となったことで今年は1月 14日が成人の日となったわけだが、いかれたカレンダーでは1月7日を成人の日としたものがあったりと、まだまだ定着したとはいいがたいものがある。という話はどうでもいいので、早速Xeon 2.20GHzシステムについて話を進めていこう。
と、その前に。昨日の巻頭言をご覧いただいた方から、Xeon 2.20GHzインストールに関しての話を詳しく…というリクエストMailを頂戴したので、今回はこの話を中心にお送りしよう。

まず、Xeon 1.70GHzとXeon 2.20GHzの違いから比較してみるが、色々な点で変更されたものが多い。

以上の変更点で要注意なのは、プロセッサのコア電圧の変化によるものだが、ご存知のように未知のプロセッサについてはマイクロコードの対応が当然のごとく成されていない（ことがほとんど）。初期のBIOSでは、PrestoniaコアのXeonは未対応であり、昨日ご紹介したBIOS履歴においても、そのことがきちんと明記されている。よって、BIOS更新を行うとなるのだが、このBIOS更新で躓く方もいらっしゃるようなので（Mailを頂戴した方をはじめとして、だろう）、改めてこの点から記しておこう。

一般的にマザーボードのBIOSアップデートは、未だにおおくが古きよき伝統に基づいた形式で行われている。つまり、DOSベースのプログラムで行うというものだが、古きよき伝統と感ずるのは、私などを含めたDOS時代からPCを扱っているユーザくらいのものだろう。加えて、DOSが死滅して久しい今日においては、DOSで起動するということもままならない。

例えば、Windows XPはNTベースなので、当然のことながらDOSは含まれていない。しかし、Windows XPによって、Windows 9xを置き換えるという位置づけとなったことから、フロッピィディスクをフォーマットするフォーマットオプションに「MS-DOSの起動ディスクを作成する」というオプションが追加になった。

これによって、DOS起動ディスクが簡単に作ることができるようになったのは確かだが、残念ながらこのDOS起動ディスクでは、Tyan Thunder i860においてのBIOSアップデートは行えないのである。

ちなみにこの手順でDOS起動ディスクを作成すると、次のようなファイル群がフロッピィディスクにコピーされる。

• AUTOEXEC.BAT
• CONFIG.SYS
• COMMAND.COM
• DISPLAY.SYS
• EGA2.CPI
• EGA3.CPI
• EGA.CPI
• IO.SYS
• KEYB.COM
• KEYBOARD.SYS
• KEYBRD2.SYS
• KEYBRD3.SYS
• KEYBRD4.SYS
• MODE.COM
• MSDOS.SYS

計15ファイル（うち2ファイルは不可視属性）が作られるが、DOSやDOS/Vを扱ってこられた方なら自明のとおり、これはいわゆるDOS/Vではない（日本語は未対応）。純粋な（という表現は不適切かもしれないが…）DOSなのである。そればかりか、一応、AUTOEXEC.BATと CONFIG.SYSの二つの設定関連のファイルはあるものの、どちらのサイズも0バイト。つまり、ファイルはあるものの、設定は何も書かれていないという状態で、完全なるピュアなDOSといえるものである。

この起動DOSディスクで、BIOSアップデートが行えないとはどういうことだろうか？
DOSを扱ってこられた方ならピンと来るだろうが、そうでない方にその解決法を見出すことを要求するのは気の毒であろう。要は、コンベンショナルメモリ不足に伴うBIOSアップデートプログラムが実行できないとわかれば、デバイスドライバとしてHIMEM.SYSを追加し、CONFIG.SYSに「DEVICE=HIMEM.SYS」と「DOS=HIGH」と記述すれば事足りるだけの話である。

ところが、Windows XPでMS-DOS起動ディスクを作成するという方法では、HIMEM.SYSが用意されないために、ハイメモリエリア（HMA）を使うのはもちろん、 286/386DOSエクステンダを内蔵するプログラムでも使えないDOSしか用意できないということになるわけだ。

今さらDOSプログラムを使用する機会というのは、BIOSアップデートくらいのものとは思うが、せっかくの「MS-DOSの起動ディスクを作成する」オプションもこの場合においては役立たずでしかない。私は、BIOSアップデートを行うためのDOS起動ディスクは、Windows 98 2nd Editionが入っているサブPCから作ったが、まだまだDOS、Windows 9x環境は残しておく必要があると痛感した次第である。
念のため、私がBIOSアップデートに使用したDOS起動ディスクの中身とCONFIG.SYSの内容を紹介しておこう。

      CONFIG.SYS
      COMMAND.COM
      HIMEM.SYS
      IO.SYS
      MSDOS.SYS

      [CONFIG.SYS]
      DOS=HIGH
      DEVICE=HIMEM.SYS

以上である。この起動DOSディスクでDOSを起動し、あとはBIOSアップデートプログラム「PHLASH16.EXE」を実行すればよい。 PHLASH16の使い方は、DOSプログラムでは定番である「/?」オプションつきでコマンドラインから実行すれば、使い方は慣れている方であれば簡単にわかる（いうまでもないが英語が不得手で、かつPC用語に疎い方にはさっぱりとは思うが…）。今回のBIOSアップデートは、DOS起動ディスクに「PHLASH16.EXE」と「2603V104.ROM」をコピーしておけば、コマンドラインから

      PHLASH16 2603V104.ROM

とタイプし実行するだけである。あとは、BIOSアップデートプログラムの指示に従えばよい。

以上でBIOSアップデートは終わりになるのだが、きちんと手順を書くだけで結構な分量（文量）となってしまった。作業時間そのものは大したことはないが、DOS起動ディスク作成でハマってしまうと結構手間かもしれない。私の場合は、Windows 9x環境が別にあったので、DOS起動ディスク作成には手間を要しなかったが、そうでない場合は救われない。特に、今回はHIMEM.SYSが必須だったのだが、Windows XPではこれが用意されないのは結構厳しいものだろう（一応、システムフォルダ内のSystem32にHIMEM.SYSはあるのだが、DOS起動ディスクにコピーされないのでは、手馴れていない方にとってはないのも同じだ）。

続いては、Xeonプロセッサの交換だが、私にとってはBIOSアップデートなどよりもはるかに時間がかかるものであった。というのは、リテールクーラー＆ヒートシンクを取り外すのに苦労したからである。

Xeonのリテールクーラー＆ヒートシンクは上記のようになっているのだが、装着するときは、とにかくこのタイプのクーラーは初めての取り付けだったため、指示どおりに従い、しっかりと装着した。ところが、これが簡単には取り外しのできない構造となっているばかりか、周辺に電解コンデンサや様々なものが所狭しと並んでいるために作業が困難を極めたのである。無理やりはずせば、再装着不可能となるのは明らかであるし、力の加減で周辺を破壊してしまったら本末転倒となる。色々と考えた結果、行き着いた方法は原始的ではあるが、止め具をラジオペンチを利用して徐々にずらしながらはずすという根気のいる作業となった。寒い部屋の中で冷や汗をかきながら所要時間トータルで50分弱。リテールクーラー＆ヒートシンクをはずすことに成功し、Xeon 1.70GHzに換えてXeon 2.20GHzを装着。今度ははずすのに苦労しないように工夫して取り付けた。
そして、動作確認のため電源を入れると、

と、無事に取り付けに成功したことが確認できたのであった。
つづく。（2002/1/14）

巻頭言 970　「Dual Xeon 2.20GHz インストール編 II」

前回は、BIOSアップデートに関して思わず長くなってしまい、インストール話をわけなければならなくなってしまった。ということで、早速前回の続きである。

Xeon 2.20GHzの取り付け作業の完了と、この起動画面を見て、無事に換装できたことを確認できたのだが、既にPrestonia（新Xeon）を導入されているSUPERMICRO P4DC系のユーザの方がご覧になると「はて？」と思われるかもしれない。というのは、Boot時のプロセッサ数が２つしか表示されていないことに対してである。私は未確認だが、Webを飛び交う情報によれば、SUPERMICRO P4DC系でPrestoniaを利用すると、BIOS設定のHyper-ThreadingのEnable/Disableを問わず、常に「CPU = 4」と表示されるようになるという話だが、Tyan Thunder i860では「CPU = 2」と表示されたのである。もちろん、Hyper-ThreadingはDisableとなったままなので、BIOSセットアップで設定を変えて行ってみることにした。

設定箇所は、「Processor」カテゴリ内の「Jackson Technology」とあるところである。これをDisabledからEnabledに変えることで、Hyper-Threadingテクノロジは利用可能となるわけだが、この状態でBIOS設定を保存し、再起動をかけると、

見事に「CPU = 4」に変更になった。つまり、BIOS設定でHyper-Threadingテクノロジを有効にすると、Boot時のBIOS表示のプロセッサ数が変更になるということである。

しかし、まだ本当に使える状態になったかどうかは何とも言えない。そこで、Dual Xeon 1.70GHzを使用していた状態でのWindows XP Professionalで起動してみることにした。念のため、BIOS設定は元に戻し（Jackson TechnologyをDisabled）、再起動をかけ、Windows XP Professionalを起動した。いつもと同じ起動画面の後、これもいつもと同じようなデスクトップが表示された。一応は、うまくいったようである。

うまくいったかどうかを確認するのに、まずはデバイスマネージャを見ることにした。結果は上のごとく、Xeon 2.20GHzが２つあると表示されている。認識は確実に行われているとなれば、続いて確認するのは、定番と言えるWCPUIDである。最新のXeonに対応したバージョンとしては3.0fが対応しているとのことなので、早速ダウンロードし実行してみた。すると……、

WCPUID 3.0fでも、きちんと表示された。どうやら、Xeon 2.20GHzへの換装は問題なく行えたようである。では２つめのプロセッサ情報でも見ようかと「Processor #2」を確認しようと▼ボタンを押したところ…… あれ？ ４つ………。

BIOS設定では、Jackson TechnologyをDisabledにしたままであるが、WCPUID 3.0fではプロセッサ数を４つと見ているようである。それでは、本家のIntel Processor Frequency ID Utilityはどうだろうかと最新バージョンの4.00.20020109（このバージョンナンバから察するようにPrestonia対応だろう）を実行したところ、

と、こちらもプロセッサは４つ扱いとなっている。
なぜ？の嵐と共に、次回に続きます。（2002/1/15）

この次の記事「Dual Xeon 2.20GHz ベンチマーク編 I」

【当時を思い起こして】
もとは、FosterコアのXeon 1.70GHzをDualで利用していたが、これをPrestoniaコアのXeon 2.20GHzに換装し、OSはそのままの状態で利用した最初の段階の記事である。今となってはどうということはないが、致命的不具合のないPrestonia対応のBIOSがなかなかリリースされなかったため、かなり最初は苦労した。また、本文中にはDOSについての記載が見られるが、2002年当初で既にDOSは過去のものとなっており、CONFIG.SYS等の説明を付けたりしたのもいい思い出だ（苦笑）。DOSが不要となった（正確にはDOSを内包した）Windows 95がリリースされて、早14年（水商売的数え方では15年）。青少年の多くがDOSを知らぬのも無理からぬことだろう。

そして現在。Dualコアプロセッサどころか、6つのコアを持つものまで出てきている。プロセッサの進歩は驚くべきものだと、改めて実感する…。