同じスレッドでの非同期操作と比較して、コンテキストの切り替えが遅い理由を知りたいです。
M 個のスレッドを実行する代わりに、N 個のスレッド (N はコアの数に等しい) を実行し、それぞれが M 個のクライアントを非同期的に処理するほうがよいのはなぜですか? 理由はコンテキスト スイッチのオーバーヘッドだと言いましたが、コンテキスト スイッチがどれほど遅いかわかりません。
質問する
1359 次
1 に答える
1
明確にするために、「M スレッドを実行する代わりに」と言うときは、N*M スレッドを意味すると仮定します (M スレッドを実行する場合、同じ合計クライアント数と一致するために、それぞれが N クライアントを処理する必要があります。同様のケースになります）。
したがって、それぞれが M クライアントを処理する N コアで実行される N スレッドと、同じ数のコアで実行される N*M スレッドの違いは、最初のケースでは新しいスレッドを作成する必要がないことです。 、コンテキストの切り替えはありません。OS スレッドの作成に必要な作業は重いため、これは利点です。別のプロセス空間、新しいスタックなどを作成する必要があります。さらに、スレッドが多い場合、OS スケジューラは実行中のプロセスを停止してアクティブ化しますが、これにも時間がかかります。スケジューラーがコアに割り当てられたプロセスを変更するたびに、おそらくこのプロセスのコンテキストもキャッシュする必要があり、多くのキャッシュ ミスが追加され、結果としてより多くの時間が追加されます。
一方、コアの数に等しい固定数のスレッドがある場合 (N-1 が推奨されることもあります)、ユーザーレベルのスケジューラで「タスク」またはクライアントを管理できます。プログラムの計算量を増やしますが、多くの OS プロセスとメモリ管理を回避して、全体的な実行を高速化します。.Net Task Parallel Library (TPL)、OpenMP、Intel の Threading Building Blocks、Cilk などの一部の現在の並列 API は、動的マルチスレッドと呼ばれるこの並列処理モデルを具体化しています。
于 2013-01-19T15:45:24.320 に答える