2

有向グラフを介してさまざまな種類のデータを処理する単純なデータ分析ツールを設計します。有向グラフは、ユーザーがある程度カスタマイズできます。各ノードは、通過するデータに対するロギング、分析、および数学演算で構成されます。グラフは、各ノードで追加の処理を行うことを除いて、多くの点でニューラルネットワークに似ています。一部のノードは通過するデータ要素に対して単純な操作を行いますが、他のノードは複雑なアルゴリズムを備えています。

グラフから結果を最速かつ最も効率的な方法で取得できるように、この有向グラフで処理をマルチスレッド化するにはどうすればよいですか?ここではメモリは問題ではなく、このタスクの初期化にかかる時間も問題ではありません。

作業をマルチスレッド化するためのいくつかの異なる方法を考えました。

  • 各スレッドインスタンスは、このグラフの開始ノードに入る各データ要素を「追跡」します。スレッドは、各ノードを通過するときにこのデータ要素にとどまり、ツリーの最後まで各ノードの処理メソッドを呼び出します。これには、基本的に、システムに入るデータ要素ごとに1つのスレッドが必要になります。もちろん、データ要素がシステム全体に渡されると、スレッドはリサイクルされます。ここでの問題は、ノードに2つの出力エッジが存在する場合です。つまり、スレッドは両方に従う必要があります(これは、スレッドプールから新しいスレッドをプルすることを意味しますか?)。

  • ノードごとにスレッドを作成し、各グラフの端にデータバッファーを作成します。ノード上のワーカースレッドは、1つのスレッドがデータを処理するのに時間がかかる場合に、データを保持するために継続的にチェックします。このアプローチの問題は、バッファの処理を開始するのに十分なデータを持つためのバッファの固有の「ポーリング」です。おそらく、グラフ構成のデータフローを単純化するために支払うわずかな代償です。

誰かがより良い方法を考えることができますか、またはあなたはどれをお勧めしますか?システム全体の待ち時間を最小限に抑え、受信データのストリームを常に処理する機能を探しています。

ありがとう!ブレット

4

1 に答える 1

3

まず第一に、スレッドを無制限に生成するのは得策ではありません (例: ノードごとのスレッド)。通常、CPU コアの最大 1.5 ~ 3 倍のスレッドが必要です (たとえば、クアッドコアの場合は 6 ~ 12 スレッド)。

thread-pool と tasksを使用することをお勧めします。このような場合、問題はタスクのサイズと言い換えることができます。

あなたが言及した方法はどちらも有効であり、それぞれに長所と短所があります。

グラフ処理のアルゴリズムはシングルスレッドのままであるため、データ入力ごとに 1 つのタスクを実装するのは簡単です。スレッド間のコンテキスト切り替え、同期、およびデータ受け渡しのオーバーヘッドはほとんどありません。

ノードに 2 つの発信エッジがある場合、この単一のタスクはそれらの両方に従う必要があります。これは、深さ優先検索幅優先検索など、グラフ トラバーサルのすべてのアルゴリズムの標準部分です。

グラフ ノードごとに 1 つのタスクを使用すると、グラフに並列処理できる「ブランチ」が多数ある場合、レイテンシを改善できます。ただし、このアプローチでは、グラフ処理のより複雑な設計が必要になり、スレッド同期のオーバーヘッドが高くなります。実際には、マルチスレッド化のコストは、グラフの並列処理によって得られる利点よりも高くなる可能性があります。

ノードに 2 つの発信エッジがある場合、2 つの新しいタスクとキューをスレッド プールに作成できます。(または、1 つのタスクをキューに入れ、他のタスクの処理を続行します。)

より困難な問題は、ノードに 2 つの着信エッジがある場合です。ノードを処理するタスクは、両方のエッジのデータが利用可能になるまで待機する必要があります。

結論:個人的には、最初のオプション (データ入力ごとに 1 つのタスク) から始めて、それでどこまで到達できるかを確認します。

于 2012-03-04T09:36:18.220 に答える