●Hyper-Threadingがイネーブルになっているけど……

　Intelが、ワークステーション用の0.13μm版「Xeon(Prestonia:プレストニア)」を発表した。以前のレポート通り、スレッドレベルの並列化技術「Hyper-Threading」は“イネーブル”にされた状態で、ただし、システムでは“ディスエーブル”にする条件付きで……。

　OEM関係者によると、ワークステーション向けPrestoniaは、Hyper-Threading機能が“オン”になった状態で出荷されるという。ただし、Intelからは、システム上ではBIOSでHyper-Threading機能を“オフ”にすることを推奨されているという。あるけれども、デフォルトでは使えないという状態なわけだ。ちなみに、新XeonではHyper-Threadingをディスエーブルにする信号ピンが加わっている。

　これはどういうことなのか。それは、今回の発表がワークステーション向けだからだ。

　Intelは、Prestoniaの立ち上げを2段階に分けた。ワークステーション向けPrestonia発表を先行させ、サーバー向けPrestoniaは2月末のIDF前後に発表する予定だ。このサーバー向けPrestoniaは、0.18μm版のマルチプロセッサ向けL3キャッシュ搭載CPUである「Xeon MP(Foster MP:フォスタMP)」と同時の立ち上げとなる。OEM関係者によると、このどちらもHyper-Threadingがオン状態で出荷され、システムでもオン状態で提供されるという。つまり、Hyper-Threadingはサーバーでのみ使えることになる。

　先月のレポート「Willametteも実はHyper-Threadingをサポート?( http://pc.watch.impress.co.jp/docs/article/20011219/kaigai01.htm )」で、IntelはPentium 4アーキテクチャにもともとHyper-Threadingをインプリメントしていた可能性が高いことを報じた。実際、その後も複数からこの推測を裏付ける情報が入っており、全てのPentium 4アーキテクチャコアにHyper-Threadingが密かにインプリメントされている可能性は極めて高い。しかし、Hyper-Threadingはすぐには“オン”にならない。PCとワークステーション、サーバーのそれぞれで下のような形で提供される。

	CPU	システム
サーバー	オン	オン
ワークステーション	オン	オフ(将来オン)
PC	オフ	オフ

　冒頭で説明したように、ワークステーション向けXeonはHyper-ThreadingがデフォルトではBIOSによってオフ状態となる。しかし、これは将来ワークステーションアプリケーションがHyper-Threadingを活かせるようになるまでという話だという。どの時点でオンになるのかはわからないが、CPU自体ではHyper-Threadingはオン状態となっている。

　それに対して、PCやエントリワークステーション向けのPentium 4では、Hyper-ThreadingはCPU自体でオフにされている。これは、おそらく2003年中盤に登場する、Northwoodの後継コア「Prescott(プレスコット)」まではオンにされない。

●ソフトウェアのHyper-Threading対応の問題

　なぜIntelがサーバーだけでHyper-Threadingを立ち上げようとしているのか。Intelはその理由について「サーバーアプリケーションは、今日、Hyper-Threadingテクノロジによってパフォーマンスの向上を現実化できる。一方、ワークステーションアプリケーションは、将来、ソフトウェアとプロセッサが進化したら、Hyper-Threadingテクノロジの恩恵を受けることができると期待されている」と、新Xeonのデータシートの中で説明している。ようは、今のワークステーションアプリケーションでは効果が薄いから、最初はサーバーだけにフォーカスするというわけだ。

　Hyper-Threadingテクノロジでは、物理的には1個のCPUが、ソフトウェアからは仮想的に2CPUに見える。つまり、疑似デュアルプロセッサになる。それなら、デュアルプロセッサ構成と同じことなのだから、せっかくインプリメントしてあるHyper-Threadingを、出し惜しみしないでオンにすればいいと思うかもしれない。恩恵が少なくても、性能が少しでも上がるならそれでいいじゃないか、というわけだ。

　ところが、そうもいかない事情がある。それは、マルチプロセッサ対応ソフトウェアの場合、Hyper-Threadingのバーチャルマルチプロセッサ上では逆に性能を大幅に落としたり、最悪CPUをスタックさせてしまう可能性があるからだ。つまり、ソフトウェア側に、Hyper-Threading向けの対応が必要になるからだ。

　Intelは、このHyper-Threading向けの対応が必要という件については、同技術を発表した昨年8月のIDFで概要を説明している。おそらく、Intelは、把握が比較的容易なサーバー向けアプリケーションでは、Hyper-Threading対応を進ませることができたが、ワークステーション向けアプリケーションまでは手が回りきっていないのだろう。サーバーアプリの場合はサポートが厚いので、ユーザーがHyper-Threading版Xeonを導入した場合に、ベンダーなりSIが適切に対応できる。しかし、ワークステーションアプリの場合は必ずしもそうではない。そのため、性能を落とす危険を考えると、Hyper-Threadingをオンにすることを推奨できなかったのではないだろうか。

●Hyper-Threadingと相性が悪いSpin-Wait

　Intelは、IDFで、Hyper-Threadingで性能が落ちる可能性については概要を説明している。問題があるのは、マルチプロセッサ対応ソフトでスレッド間の同期を取るために使われる「Spin-Wait Loop」と呼ばれる手法だ。これは、2つのスレッドが別々なプロセッサ上で走っていて、片方のスレッドがある処理を終えるまでもう片方のスレッドを待たせておきたい場合などに使われる。Spin-Waitでは、待つ方のスレッドはループに入って、もう片方のスレッドが、処理を終えるまで意味のないループ処理を継続する。例えば、ループ内で特定のメモリアドレスを参照、もう片方のスレッドがそのアドレスを書き換えた場合に、ループから抜け出すようにする。

　Intelの説明によると、この手法は物理的にCPUが複数ある場合はいいが、Hyper-Threadingでは大きな問題を引き起こすという。それは、Spin-Waitに入ったスレッドのループが、CPUのリソースを取ってしまうからだ。Hyper-Threadingの場合、実際には2つの仮想CPUが同じ物理CPUのリソースを共有している。そのため、Spin-Waitに入ったスレッドがリソースを浪費してしまうと、もう片方のスレッドの処理が滞ってしまうケースが出てくる。

　そのため、IntelはPentium 4やXeon向けのプログラムではこの問題を避けるために「PAUSE」命令を使うか、OSコールでスレッドをサスペンドさせるように推奨している。実際、Intelはこの問題についてのプログラミングガイド「Using Spin-Loops on Intel Pentium 4 Processor and Intel Xeon Processor」を、Pentium 4発表よりはるかに前、2000年2月にリリースしている。かなり前から、この件については注意を促していたのだ。ただし、Hyper-Threadingのことは秘したままで。

　今回、Hyper-Threadingへのソフトウェア側の対応が遅れているのは、IntelがHyper-Threadingの存在を明らかにしたのが遅かったからだ。Pentium 4アーキテクチャにもともとインプリメントされていたと見られるHyper-Threadingの発表が遅れた理由については先月のコラム「0.13μm版Pentium 4にもHyper-Threadingテクノロジを搭載!?( http://pc.watch.impress.co.jp/docs/article/20011214/kaigai01.htm )」で推測したが、特許問題などが絡んだ可能性がある。いずれにせよ、助走期間がないため、IntelとしてもHyper-Threadingを浸透させたくてもできない状況にあると見られる。それが、段階的なHyper-Threadingオンという形になっていると思われる。

　だが、Intelは、今後はHyper-Threadingへの対応を急いで促す。来年の中盤、Prescottなどが登場する時点では、ソフトウェア側がレディになっているようにするというのがゴールだろう。逆を言えば、それまでは、Pentium 4アーキテクチャは、インプリメントされているフィーチャであるHyper-Threadingをオフにしたままの状態となる。つまり、CPUの発表から2年半も、そのアーキテクチャの真価が発揮できない状態が続くことになってしまう。

□バックナンバー

(2002年1月10日)

[Reported by 後藤 弘茂]