アカウント名:
パスワード:
サーバ用途ではHyper-Threadingで性能がむしろ低下することもあるので必ずしもマイナスではないのでは
ここでもそういった議論あったし、検索すればそういった事例もいろいろhttps://srad.jp/comment/1402115 [srad.jp]
このストーリーで紹介されているMicrosoftの記事は面白いですね。https://technet.microsoft.com/ja-jp/library/cc137784.aspx [microsoft.com]
とはいえ、記事では物理コアあたりのコンテキストスイッチが多すぎるのが性能悪化の原因と記載されています。CPUとI/Oの両方が高負荷になるソフトウェア(RDBMS)において、実行時にコア数を考慮した高度な最適化が施されている場合に、論理コア数に基づいて最適化が行われたために、コンテキストスイッチが過度に増加して性能悪化につながった事例のように見えます。
基本的には過渡期の現象で、物理コアを意識した最適化を実装すれば回避できる性能低下に思えました。
ハイパースレッディングって論理コアにすることでコンテキストスイッチ減らす技術かと思ったけどぜんぜん違うのね。コンテキストスイッチが発生するならOSのスケジューラがやっても同じじゃないか…。
それを制御するのがOSのスケジューラなんだからイマイチ意味が通らない。
CPUバウンドじゃないスレッドを待機させるならHTは有効に働くでしょう。CPUバウンドなスレッドが非常に多い場合、論理コア毎にタイムスライスを割り当てるナイーブな実装だと物理コアに対して倍のコンテキストスイッチが発生し、計算コアの利用効率向上を上回るオーバーヘッドが生じたって話では?
コアの共有を意識したスケジューラを実装するのは勿論OSの役目ですし。
論理コアごとにタイムスライスを割り当てることのどこがナイーブなのかよくわかりませんが…。スレッド数が2倍あったからといって、タイムスライスの長さを2分の1にする理由はないはずなので、それだけでコンテキストスイッチが倍になる理由にはならんのでは。
どっちにしろ想像ですが、コンテキストスイッチの増加要因としては、priority boostされたI/O待ちスレッドの起床のほうがありそうじゃないですかね。
例えばHZが100だったら(今時は可変でしょうが)10msec毎に論理コア毎に必要ならスイッチするわけで。物理コアで見ると2回行われるんじゃないかな。まあ初期のUNIXレベルのスケジューラなら、ですが。
> ハイパースレッディングって論理コアにすることでコンテキストスイッチ減らす技術かと思ったけどぜんぜん違うのね。
違いますね。OoO用のハードウェア資源は常に100%使いきってるわけではなく遊んでいる演算器その他がたいてい存在するので、仮想的なスレッドを増やして、遊んでるハードウェアを使い尽くしてその分だけ性能を上げてやろうという技術です。ただしスレッドを増やすとメモリフットプリントは増加するので、ボトルネックがキャッシュ容量やメモリバンド幅だった場合には、かえって性能が低下すると。
各論理CPUをフル負荷かけた状態を想定すると、メモリバスの衝突なんかでストールしている時間が増えるので、性能低下することがある。特に、CPUのキャッシュに収まらないような処理を大量に実行していれば、その傾向は顕著になる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
Hyper-Threadingと性能 (スコア:2, 興味深い)
サーバ用途ではHyper-Threadingで性能がむしろ低下することもあるので必ずしもマイナスではないのでは
ここでもそういった議論あったし、検索すればそういった事例もいろいろ
https://srad.jp/comment/1402115 [srad.jp]
Re:Hyper-Threadingと性能 (スコア:1)
このストーリーで紹介されているMicrosoftの記事は面白いですね。
https://technet.microsoft.com/ja-jp/library/cc137784.aspx [microsoft.com]
とはいえ、記事では物理コアあたりのコンテキストスイッチが多すぎるのが性能悪化の原因と記載されています。
CPUとI/Oの両方が高負荷になるソフトウェア(RDBMS)において、実行時にコア数を考慮した高度な最適化が施されている場合に、
論理コア数に基づいて最適化が行われたために、コンテキストスイッチが過度に増加して性能悪化につながった事例のように見えます。
基本的には過渡期の現象で、物理コアを意識した最適化を実装すれば回避できる性能低下に思えました。
Re: (スコア:0)
ハイパースレッディングって論理コアにすることでコンテキストスイッチ減らす技術かと思ったけどぜんぜん違うのね。
コンテキストスイッチが発生するならOSのスケジューラがやっても同じじゃないか…。
Re: (スコア:0)
それを制御するのがOSのスケジューラなんだからイマイチ意味が通らない。
CPUバウンドじゃないスレッドを待機させるならHTは有効に働くでしょう。
CPUバウンドなスレッドが非常に多い場合、論理コア毎にタイムスライスを割り当てるナイーブな
実装だと物理コアに対して倍のコンテキストスイッチが発生し、計算コアの利用効率向上を上回るオーバーヘッドが生じたって話では?
コアの共有を意識したスケジューラを実装するのは勿論OSの役目ですし。
Re: (スコア:0)
論理コアごとにタイムスライスを割り当てることのどこがナイーブなのかよくわかりませんが…。
スレッド数が2倍あったからといって、タイムスライスの長さを2分の1にする理由はないはずなので、
それだけでコンテキストスイッチが倍になる理由にはならんのでは。
どっちにしろ想像ですが、コンテキストスイッチの増加要因としては、priority boostされたI/O待ちスレッドの起床のほうがありそうじゃないですかね。
Re: (スコア:0)
例えばHZが100だったら(今時は可変でしょうが)10msec毎に論理コア毎に必要ならスイッチするわけで。
物理コアで見ると2回行われるんじゃないかな。まあ初期のUNIXレベルのスケジューラなら、ですが。
Re: (スコア:0)
> ハイパースレッディングって論理コアにすることでコンテキストスイッチ減らす技術かと思ったけどぜんぜん違うのね。
違いますね。
OoO用のハードウェア資源は常に100%使いきってるわけではなく遊んでいる演算器その他がたいてい存在するので、
仮想的なスレッドを増やして、遊んでるハードウェアを使い尽くしてその分だけ性能を上げてやろうという技術です。
ただしスレッドを増やすとメモリフットプリントは増加するので、ボトルネックがキャッシュ容量やメモリバンド幅
だった場合には、かえって性能が低下すると。
Re: (スコア:0)
各論理CPUをフル負荷かけた状態を想定すると、メモリバスの衝突なんかでストールしている時間が増えるので、性能低下することがある。特に、CPUのキャッシュに収まらないような処理を大量に実行していれば、その傾向は顕著になる。