3

私はパイプライン パターンについて、並行性を活用するという点で一般的で役立つパターンとしてよく読んでいます。しかし、Task Parallel Pattern と比較して Parallel Pipeline パターンに何か利点があるのだろうか。

パイプラインに A、B、C の 3 つのステージがあるとします。データを処理する必要があるとき、A はそれを受け取り、処理して B に渡します。次のデータ チャンクが入ってくると、同じことが起こり、A と B同時に働いています。

したがって、パイプラインのさまざまなステージを並行して実行できますが、(タスク並列処理パターンのように) 並行して動作する3 つのパイプラインを使用すると、まったく同じ状況が得られます。2 つのデータ チャンクが次々に受信されると、最初のチャンクがパイプライン 1 によって取得され、次のチャンクがパイプライン 2 によって取得され、両方のチャンクが同時に処理されます。

さらに、並列パイプラインの多くの問題を簡単に想像できます。ステージ間のバッファーがブロック (またはオーバーフロー) する可能性がある、処理速度の点で 1 つのステージが支配的であるため、最も遅いステージより前のすべてのステージを待機する必要があるなど...

これらの問題は、タスク並列処理パターンには存在しません。さらに、このパターンは、チャンクがパイプラインの最初のステージで処理できるよりも速く到着する場合 (またはチャンクを同時にフェッチできる場合) により柔軟です。

では、なぜ並列パイプライン パターンを使用する必要があるのでしょうか。

アイデアをお寄せいただきありがとうございます。

4

1 に答える 1

4

パイプライン A=>B=>C があり、それ以上の制限がない場合、それは実際には役に立ちません。function を使用することもできましたC(B(A(input)))

パイプライン段階でさまざまな程度の並列処理を許可すると、この概念はより便利になります。ステップ B が SSD にアクセスし、最大 4 つの同時アクセスが必要な場合があります。セマフォで同じことを達成できます。

A、B、および C の並列度が 1 に制限されている場合、パイプラインにも価値があります。パイプライン モデルでは、3 つのノードすべてを同時に実行できます。あなたが言うように「3つのパイプライン」を使用することは、並列処理の制限が想定されているため不可能です(または、パイプラインソリューションと同等の3つのロックが必要です)。

ノード間のバッファリングが必要な場合があります。おそらく、A は、B が時間をかけて処理する高いバーストを発することはめったにありません。バッファリングは、A の動作を維持し、停止しないようにするのに役立ちます。

場合によっては、パイプラインではなく、内外に分岐する (場合によっては結合する) データ フロー ネットワークです。

全体として、データフロー ネットワークのユース ケースを見つけることはほとんどありません。多くの場合、データの並列処理を使用し、適切なロックとセマフォを使用する方が簡単です。しかし、これは私が通常働いているドメインのせいかもしれません.YMMV.

于 2016-08-24T11:20:28.837 に答える