私のゲームはマルチスレッド アーキテクチャを使用しており、スレッドは次のように配置されています。
現在、(hardware_threads - 3) 個のワーカー スレッドがあり、未使用のハードウェア ユニットごとに 1 つずつありますが、「リソース」スレッドと「ネットワーク」スレッドを 1 つのユニットに結合して、もう 1 つ追加したいと考えています。アイドリング時間が長い。
そうです、これは悪い考えです。1 つのジョブに対して 1 つのスレッドを設計するのは簡単に思えますが、実際にはそうではありません。特に、一部のジョブが他のジョブより重い場合はなおさらです。また、十分なスレッドを作成していません。通常、現在実行されていない他のスレッドのスラックを考慮して、それよりもいくつか必要です。
ここでの根本的な問題は、独自のスレッド バックエンドを実装していることです。これは悪い考えです。TBB のようなものに移行する必要があります。TBB は、これらすべてを処理してくれます。Intel のエンジニアは、プロファイリングと作業にあなたよりもはるかに長い時間を費やしました。
これが価値のある最適化であるかどうかについては、おそらくそうではありません。十分な数のワーカーを作成してロードしたままにしておくだけで、ブロックしているリソース/ネットワーク スレッドは実際には大きな違いはありません。
スレッドは、作業を分散したり、今待っていても問題にならない何かが起こるのを待ったりするのを避けるのに最適です。したがって、スレッドを使用することは、デザインにとって間違いなく適切なアイデアです。
必要なスレッドの数と、スレッドを増やすか減らすかが「価値がある」かどうかについては? これは、答えるのがはるかに難しい質問です。CPU を集中的に使用するスレッドの場合、システムにある CPU コアの数よりも多くのスレッドを使用しても意味がありません。追加のスレッドを使用しても、より多くの作業が行われないためです [ソフトウェア アーキテクチャ上の理由で、より多くのスレッドを使用する必要があるかもしれませんが、通常はソフトウェアが複雑になりすぎているためです。うまくいけば、そこにたどり着かないでしょう...]
待機するため CPU をあまり使用しないものについては、スレッドの数は「コードで処理しやすくするもの」のほうが多くなります。明らかに、何千も持つのはおそらく悪い考えですが、1 つまたは 2 つまたは 3 つではありません。大した違いはないでしょう。明らかに、「スレッドに次に何をすべきか、いつ結果を待つ必要があるかをどのように伝えるか...」などと同じ問題を抱えているでしょう。アイドル状態のスレッドはシステムに対してあまり「行いません」パフォーマンス - 少量のスタック メモリとさらに少量のスレッド制御データを消費しますが、非常に少量であるため、大量のデータを取得していない場合は問題になりません。
要約すると、盲人が豚の毛を刈ったときに言ったように、おそらく「非常に小さな羊毛のために多くの悲鳴を上げる」 - 言い換えれば、多くの仕事、あまり利益はない.