スレッド数：計算集約型vs IO集約型操作？
私はこれで以下のステートメントに出くわしました blog
IOファイルのコピーなどの集中的な操作はCPUを使用しないため、より多くのスレッドを使用できますが、計算集中的な操作ではコア数以下のスレッドを使用する必要があります
スレッド数がコアよりも多くなる可能性がある理由/ロジックの推論が得られないIO計算集中型の操作の場合は低くする必要があるのですか？
スレッドは何らかのリソースを求めて競合します。使用可能なリソースよりも多くのスレッドがリソースを必要とする場合、それらは互いにブロックしているだけであり、タスクの切り替えによるオーバーヘッドがあります。問題は、どのようなリソースがここに含まれているのかということです。
CPUバウンドスレッドの場合、リソースは通常1つのCPUコアです。コアがいくつかのリソースを共有する場合があります。キャッシュまたはFPU。特に、Intelのハイパースレッディングは、CPUにバインドされたスレッドには役立ちません。したがって、すべてのコアを「使用」するずっと前に、高速化が見られなくなる可能性があります。
I/Oバウンドスレッドの場合、問題はここで正確な種類のI/Oが関係していることです。競合するリソースがハードディスクドライブである場合、複数の同時アクセスにより処理速度が低下します。競合するリソースがネットワークインターフェイスである場合、インターフェイスの合計帯域幅を超えない限り、任意の数のスレッドが問題なくリソースにアクセスできます。
I/Oバウンドスレッドの場合、CPUコアの数は完全に無関係です。実際、並列I/Oを行うために複数のスレッドは必要ありません。ここでは、非同期I/Oおよびイベントベースのシステムで十分です。
スレッド数に関する規定は、アプリケーションのロジックとは関係ありません。スレッドが計算にバインドされているか、I/Oにバインドされているかに関係なく、アプリケーションのコアよりも多くのスレッドを使用することは理にかなっています。
規定の理由は、コアよりも計算にバインドされたスレッドが多い場合、追加の計算にバインドされたスレッドが待機し、計算が前進しないためです。
T = 20スレッド、C = 8コアを検討してください。 run-q（実行可能なスレッドのリスト）を検討してください。最大8つが実行可能で、残りは実行のチャンスを待つキューに座っています。
スレッドの大部分がI/Oバウンドである（または実際に何かをブロックしている）場合-とにかく「実行可能」にならず、CPU使用率に影響しません。
アプリケーションのジョブがすべてのCPUコアをホット（100％で完全に実行）に保つことであると考える場合、少なくとも十分な（計算集中型）スレッドを確保した後で、計算集中型スレッドを追加してもCPU使用率は向上しません。各（論理）コア。
注-これは、この理論（およびおそらくブロガー）の背後にある思考プロセスです。それは本当に真実ではありません。プロセッサーの能力を最大限に引き出す方法を決定する際に考慮に入れられる要素は他にもたくさんあります。 1つの考慮事項は、すべてのコアが動作するように各コアをスローダウンすることです。したがって、各コアに十分な計算スレッドができるまでは、計算スレッドを追加すると、速度が低下するだけでなく速度が低下する可能性があります。
また、スレッドの管理にはかなりのCPUオーバーヘッドがあります（スレッドの割り当て/管理方法によっては、メモリの局所性の問題が発生する可能性があります）。
ADVICE/SUMMARYだから-個人的には、この種の推論については心配せず、アプリケーションの論理構造については心配しないでください。何が意味をなし、どのように機能させるかについてです。スレッドプールを使用します。また、サイズを構成可能にします。
私の0.02ドル。