コンテキストスイッチの特定の最悪のシナリオがどのように起こるかを理解したいと思います。 1つのプロセスを実行するCPUコアが10個あるとします。すべてがCPUを大量に消費し、スレッドがスリープしていない(I/Oを待っている)コンテキストスイッチ:最悪のシナリオではどうなりますか?
(私が主流の現代のパーソナルコンピュータアーキテクチャやシステム、WindowsやLinuxで一般的にx64のを主としています...)私が間違っている場合
が私を修正:10 CPU/RAM集中的な独立したスレッドを実行することはほとんどあり多くの場合、ほぼ最適な状況です。コンテキスト切り替えに費やされる時間は、ごくわずかです。 RAMキャッシュのリセットを引き起こすラウンドロビン方式で異なるコアにスレッドを再属性することを時々決定することがありますが、ほとんどの場合、各スレッドが単一の固定コアで実行されているかのように動作します。
すべてのスレッドが共有するため、メインRAMバスだけが制限される可能性がありますが、ここで私が興味を持っているポイントではありません。スレッドの数を減らしても、スループットは向上しません。
ここではまだコアが10個ありますが、1000個のスレッドが実行されているとします。スケジューラは理論的には、1秒間に10スレッドを実行し、次に10スレッドを実行することはまれに(1秒ごとに)切り替えることになりますが、全体としては最適なパフォーマンス(スループット)に近いものになります。
しかし、そうではないようであり、スレッドが集中的に切り替えられ、強く最適ではないパフォーマンス(スループット)を引き起こすようです。私はそれについて正しいですか?この準最適なパフォーマンスの主な原因は何ですか?たとえば、1秒あたりのスイッチ数、切り替えによるパフォーマンス低下などの大きさの目安がある場合は、数があればいいと思います...
WindowsのようなOSでは、プロセッサを別のプロセッサに切り替える前に3クロックティックでスレッドを実行できます。だから約47ミリ秒。コンテキストスイッチの実際のコストは、プロセッサキャッシュ内のデータをいかに悪いかに大きく左右されます。最近の最悪のケースは約15,000サイクルです。したがって、約0.01%のオーバーヘッドである3 GHzコアでは、何千ものスレッドを積極的に実行することはスループットにとって決して良いことではなく、計算サイクルは有限のリソースです。 –