- - PR -
Hyper-ThreadingテクノロジはPCに革命を起こすか？
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-11-21 14:33
MPEG-2のエンコード。いやほんと、こればかりはもっともっと早いCPUが欲しくなります。Athlon MP/1.2GHz×2なので、最速とは言いませんが遅くはないはずのCPUパワーでも全然足りません。エアチェックからクリップしてDVD-Rに焼くには相当気合いを入れないと、やる気になるのが難しい状態です。Hyper Threadingが有効かどうかはわかりませんが。 | ||||||||||||
|
投稿日時: 2002-11-21 17:42
Windows OSにおけるHTのサポート状況などを説明した文書が
以下にあります。 Windows Support for Hyper-Threading Technology http://www.microsoft.com/hwdev/platform/proc/ht-windows.asp この中の、「5. Hyper-Threading Features Supported in Windows XP and Windows .NET Server」にあるように、HT対応の Windowsでは、同一スレッドを同一物理CPUに積極的に割り当てるように しているようです。逆に言うと、こういう考慮をしていないOSでは、 同一物理CPUに対して、異なるプロセスが割り当てられ、結果として、 １プロセスあたりで利用可能なキャッシュの量が少なくなります。 その分、それぞれのプロセスごとのキャッシュミスが頻発し、 全体としては、パフォーマンスが低下することになります （単一スレッドしか持たないプロセスばかりのベンチマークは論外ですが）。 LinuxのHT対応はよく知りませんが、単にHT Pentium 4の型番 を認識して表示するだけでは、早くならないと思います （いわゆるステッカーチューンて奴？ まさかそんなことはないだろうが。 ^^;;）。 こういう話は、確か昔のWindows NT 3.51 と NT 4.0のMPS対応でも ありましたよね？（もっと前のバージョンだったか？） NT4.0ではCPU Affinityの概念が取り入れられ、同じスレッドは、 再スケジュール後にもなるべく同じCPUに割り当てられるように なりました。そうでなかった 3.51では割り当てられるCPUが固定 されていなかったので、そのたびにキャッシュのフラッシュや 再ロードが起こり、パフォーマンスがあまり向上しなかったようです。 それはともかく、3GHzを超えるCPUを使っていて遅いじゃないかと いう人がいるなんて。ううっ、なんて贅沢な悩みなんだろう（^^;;）。 | ||||||||||||
|
投稿日時: 2002-11-22 00:54
ちょっとだけ調べてみると、 Fred Pollack, "New Microarchitecture Challenges in the Coming Generations of CMOS Process Technologies", Micro32 Conference, Haifa Israel. Nov'99 に行き着きました。 もう少し具体的で、現在記事で見かける数値については、 http://www.theregister.co.uk/content/61/25774.html で記述されていました。 RWTでP.DeMone氏の記事にもあったように覚えています。 どちらにしろ、おそらく、論理スレッド(プロセッサ)数を現在の機能ユニット数上で増やしても30%位まで、そのアプリケーションの性能は向上しない(30%位でスピードアップが飽和する)ということを言いたいのだと思います。 Amdahl's Lawを使って考えてみると、一つのアプリケーションに並列演算(実行)できるところがどれだけあるか、並列演算できる機能ユニット数はいくつか、の2つの点がスピードアップの鍵ということから、30%の性能アップと決定づけた性能評価に使われたアプリケーション群は逆算すると最大50%程度のコードが並列可能ということで、単一アプリケーションに対してのスピードアップにHTはそれほど貢献しない(並列処理効果を望めない)、むしろ複数のアプリケーションを走らせ、依存関係のない命令を複数個発行した場合の方が複数の論理プロセッサのためのHTとして活かしたほうがいいと思います。 また、単一アプリケーションについては投機的スレッド生成実行技術が必要でしょう。 ですから、これからは複数のアプリケーションを実行させた場合の性能評価をどうするかが問われるのではないでしょうか。 HTは物理的マルチプロセッサ環境への移行とプロセス(スレッド)間処理を物理的な制約から引き離すための布石だと思います。
単一アプリケーション内の各スレッドとそれらの並列処理が最適化されるということですからね。 Intelのいう最大30%の性能向上が見受けられるのではないですか。
この求め方は?です。実行時間Tは一般に T = CPI*N*Tcycle CPI:命令当りの平均サイクル数、N:動的命令発行数、Tcycle:クロック周期時間 です。 MP係数ってなんですか? 単位時間当りの平均論理プロセッサ数ですか? でしたら、0.5*1.8=0.9は成り立ちません。 90%というのは論理プロセッサ数1.8上での値ではないのですか? 90%というのは論理プロセッサ間通信やキャッシュミスが未改善(未最適化)だからではないでしょうか。 | ||||||||||||
|
投稿日時: 2002-11-22 08:25
MP係数は、システムの設計を行う際にSMPのシステムでいくつのCPUが必要となるのか概算するのに使用する値です。MP係数自身は、理論性能を計算によって論理的に求めたものではなく、ベンチマークや、各種システムでのモデルテストなどの結果から、総合的に求めたものです。理論設計に基づく値ではなく、現在実際に稼動しているシステム群における実測性能値による数値の平均です。SEは、この数値を見て必要なCPU数を見積もることになります。２CPUのときのMP係数といった場合には、CPU数を1個から2個に増やした場合にどのくらいの性能向上が見積もれるかということであり、その係数が、1個のときの1.8倍であるということです。
面白いことに、Xeon 512KBの場合には、Hyper-Threadingテクノロジが"無効な"物理CPUが２個のときのMP係数は、(まともにマルチプロセッサに対応しているとは思えない一部のOSを除いて)OSの種類を問わず、また、メーカを問わず大体1.8倍程度となります。1+1は決して2にならないのがCPUの足し算です。4CPUの時のMP係数なんか低すぎて愕然としたものです。システムによっては、クラスタ化した方が良い理由がよく分かります。 Hyper-Threadingテクノロジによって、こういった単純な性能の見積もりモデルは、見直しを余儀なくされることは確かなようです。 | ||||||||||||
|
投稿日時: 2002-11-23 00:18
なるほど。 どのように値を求めているかが気になります。 一息ついて、2論理CPU上で1.8倍という値を考えると、プロセス間通信(スレッド制御)オーバヘッドと、MP係数計測カーネルをどう扱うかによりますね。 それらとプロセス間キャッシュコンテンション(つまりキャッシュミス)が効いている結果ではないでしょうか。 おまけ： Simultaneous Multithreading Projectのリンク http://www.cs.washington.edu/research/smt/ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。