3

Task Parallel Library を使用してソリューションの並列検索を実行する小さなライブラリに取り組んでいます。現在の設計は次のように機能します。

  • ConcurrentQueue は検索の結果を受け取り、
  • メイン タスクはループとして機能し、バックグラウンド スレッドとして動作します。新しいソリューションがキューに到着すると、キューから取り出して処理し、新しいタスクで新しい検索を開始します。
  • 検索は独自のタスクで起動され、完了するとその結果がキューに返されます。

[Eric J の回答に基づく編集: 関連するアクティビティは完全に CPU に依存しており、IO は関与していません]

フレームワークは今のところそのままでうまく機能します。ただし、トリガーされる検索タスクの数は完全に制御できます。私の理解では、TPL は今のところ状況を非常にうまく処理しますが、システムに大量の検索を押し込んでも並列処理は増加しません。システムで利用可能なコアの数に制限され、一定のレベルになると非生産的になります。

私の質問は次のとおりです。実行される検索タスクの数を制限することで TPL を「助ける」ことができますか? もしそうなら、その上限をどうするかを決定するにはどうすればよいでしょうか? たとえば System.Environment.ProcessorCount に基づいて制限するのは適切でしょうか?

4

1 に答える 1

4

まず、ここで実際のパフォーマンスの問題が発生しない限り、TPL に任せます。それはそれでかなり上手です。

実際のパフォーマンスの問題を解決するためにタスクの数を制御する必要がある場合は、何がパフォーマンスを制限しているのかを理解する必要があります。タスクは CPU バウンドですか? IOバウンド？スワッピングの原因となっている物理メモリが不足していませんか?

制限要因が何であるかがわかれば、その要因を確実に監視し、その (ランタイム) 測定値に基づいて実行中のタスクの数を調整できます。たとえば、タスクが CPU バウンドであるが IO 時間がいくらかある場合、コア数に基づくハード制限は近いですが、最適ではありません。代わりに、全体的な CPU 使用率に基づいて制限します。 これは、マシンがこのタスクの処理にほとんど専念していることを前提としています。そうでない場合、手作業によるチューニングは非常に複雑になり、エラーが発生しやすくなります。

于 2012-06-08T02:49:03.060 に答える