問題タブ [fork-join]

フローで次の fork と join パターンを使用しています。並列処理は問題なく動作します。ただし、例外処理に問題があります。ルーターの VM 応答インバウンド エンドポイントで発生する処理の例外戦略を実装したいと考えています。ただし、キャッチ例外戦略ブロック内から応答に書き込もうとすると、何も起こらないようです。例外が発生した場合、catch ブロックからログ ステートメントを確認できますが、ブラウザの応答がハングするだけです。提案してください。

Fork/Join Tutorialを見た後、大きな階乗を計算するためのクラスを作成しました。

私が持っている質問は、タスクを細分化するしきい値をどのように決定するかです。フォーク/ジョインの並列処理に関するページを見つけました。

fork/join 並列処理を使用するアルゴリズムを実装する際に考慮すべき主な事項の 1 つは、並列サブタスクを fork するのではなく、タスクが順次計算を実行するかどうかを決定するしきい値を選択することです。

しきい値が大きすぎると、プログラムは使用可能なプロセッサ/コアを十分に活用するのに十分なタスクを作成しない可能性があります。

しきい値が小さすぎると、タスクの作成と管理のオーバーヘッドが大きくなる可能性があります。

一般に、適切なしきい値を見つけるには、いくつかの実験が必要です。

では、しきい値を決定するには、どのような実験を行う必要があるでしょうか?

この fork/join 計算の例があります。誰かがここでどのように機能するかを簡単に説明してもらえますか?

私は並列プログラミングプロジェクトをやっています。要件は、立方体の格​​子 (3D 次元で最大 1000 要素) 内の文字列のリストを検索することです。リストの最大サイズは 1000 で、文字列の最大長は 100 です。

3 つの ForkTask を作成します。X 次元 (NxN 2D 配列)、Y 次元 (NxN 2D 配列)、Z 次元 (NxN 2D 配列) で検索します。タスクごとに、2D 配列で文字列の検索を開始し、このための ForkTask を作成します。2D配列で文字列を検索する機能がありました。

スレッドだけでなく ForkTask もたくさんあることがわかります。検索のパフォーマンスを向上させ、時間を短縮するために、task.join() が true の場合、残りのタスクをキャンセルすることを確認します。

それは賢明なアプローチですか？誰でも私に推薦、提案、アドバイスを与えることができますか?

ありがとう

質問

Fork-Join は現在の誇大広告であり、多くの回答で推奨されているように思われるため、実際の速度について調査してみませんか?

これを測定するために、数値の加算を行う小さなプログラム (以下のコードを参照) を作成し、スレッド数、フォークの深さ、フォークの広がりなどのさまざまなパラメーターを使用して分岐し、実行時間を測定しました。実際の計算に費やされた時間と分岐に費やされた時間。

抽象的な答え

ForkJoin は適切に実装されていますが、各フォークのコストが非常に高いため、タスクを並列化する方法としては非常に非効率的です。素朴な問題に最適化された実装は、99% のスレッド実行時間 (Fork-Join で測定されたすべてのものを上回る) を簡単に達成できるため、そのような実装は常にFork-Join 実装よりも高速です。さらに、フォークごとの実際のタスクが小さい場合、Fork-Join 実装は、シングルスレッドの線形実装よりもはるかに遅くなる可能性があります。

したがって、Fork-Join は、他の実装に比べてパフォーマンス上の利点がないため、コードのアーキテクチャに役立つかどうかの問題です。したがって、Fork-Join は次の場合にのみ使用する必要があります。

• パフォーマンスは重要ではなく、タスクは他のタスクの結果が続行されるまで頻繁に待機する必要があります。したがって、基本的に、Fork-Join 構造が単純な実装よりもタスクを大幅に簡素化する場合です。

• 実際のタスクは fork のコストを大幅に上回るため、損失は無視できます。私のテストでは、2 つの値を追加するループは、妥当なパフォーマンスを得るために、フォークごとに少なくとも 10000 回ループする必要がありました。

編集：私が指摘したより詳細な分析については、こちらを参照してください。

テスト設定

私のプログラムでは、RecursiveTask に与えられた N のフィボナッチ数列を計算させました。これにより、実際の計算が 3 つの代入と 1 つの追加に削減されました。特定の CPU では、これはマイナーなタスクです。

テストでは、スレッドの量、タスクごとのフォークの量、およびフィボナッチ ループの長さを変化させました。さらに、async パラメーターを使用していくつかのテストを行いましたが、これを false に設定しても計算時間がわずかに短縮されるだけだったので、スキップしました。結果に大きな違いがなかったため、拡散パラメーター (フォークごとのフォーク) もほとんどスキップされました。

一般に、計算時間は非常に安定しており、タスクに費やされる実際の時間の割合は通常 1% 未満で変動します。したがって、各テスト セットは、アイドル状態のシステムで約 5 回 (数値が不安定な場合はそれ以上) 実行されました。 4 コア (+4 ハイパーコア) の場合、実行時間の中央値が選択されています。

適切な実行は、さまざまなテスト変数を通じて検証されています。特に、使用される実際のスレッドの数は、最初に指定された並列処理パラメーターと決して変わらないことが検証されています。

詳細なテスト結果

どこ：

• Time totalメインスレッドの観点から全体の計算にかかった合計時間です。
• Time taskは、すべてのフォークを組み合わせたフィボナッチ数列を実際に計算するのに費やされた時間です。
• Time task percentageは、スレッド化による相対的なゲインです (時間タスク / 合計時間)。
• spread->depth(設定された) スプレッド (フォークごとのフォーク) と (計算された) フォークの深さです。
• threads実際に使用されたスレッドの量です。
• task-time/threadフィボナッチ数列全体の計算に各スレッドが実際に費やした時間です。

拡散 -> 深度テスト:

結論: フォークの数はマイナーな影響しか与えません (フォークが少ないほど良い)。実装はかなり洗練されているようです。他の設定でも同様の結果が得られたので、ここでは省略します。

Fib(0) (分岐に費やされたほぼすべての時間)

結論: 非常に小さなタスクでは、ほとんどの時間が fork に費やされ、単一スレッドの実装は fork-join セットアップよりも約 5 倍速くなります。複数のスレッドがあっても、Fork-Join を使用してパフォーマンスを向上させることは不可能です。

フィブ(100)

結論: マルチスレッドが影響を及ぼし始めている一方で、シングルスレッド実行の損益分岐点に近づいているようです。それでも、シングル スレッドの実装は、どの Fork-Join セットアップよりも高速です。

フィブ(1000)

結論: マルチスレッド実行の時間はほぼ線形のゲインで安定し始めますが、スレッドあたりの計算時間の約 20% はフォークに費やされます。この時点で、フォークはスレッド化によってパフォーマンスを向上させることができますが、単純な実装は依然として著しく高速です。

Fib(10000)

結論: この数では、計算はフォークのコストを上回ります。単純な実装でもわずかに高速ですが、別の方法でタスクを実装するのがはるかに困難であった場合、分岐による損失は無視できます。

コード

間違いを指摘したり、改善のための提案をしたりしてください。いくつかのボーナスポイントについて、最も価値のある回答を受け入れます。

ThreadPoolExecutor と CompletionService を使用した Java のコードがいくつかあります。タスクは大きなバッチでプールに送信されます。結果は完了サービスに送られ、バッチ全体が完了するのを待たずに、利用可能な場合に完了したタスクを収集します。

プール内のワーカーの総数は MAX_NUMBER_OF_WORKERS です。利用可能なワーカーなしで送信されたタスクはキューに入れられます。最大 20 個のタスクをキューに入れることができ、その後、タスクは拒否されます。

このアプローチに対応するGparsは何ですか?

gpars 並列処理に関するドキュメントを読んだところcollectManyParallel()、anyParallel()、 、 などの多くの潜在的なオプションが見つかりましたが、どれをテストすればよいかわかりfork/joinません。ドキュメントで比較として「完了」または「完了サービス」についての言及を見つけたいと思っていましたが、何も見つかりませんでした。gpars の経験者からどこから始めるべきかについての方向性/指針を探しています。

この投稿を読み終えたところです: Java-7 ForkJoinPool に対する Java-5 ThreadPoolExecutor の利点は何ですか? 答えはまっすぐではないと感じました。

Java 7 の Fork-Join フレームワークと古いソリューションの間のトレードオフは何か、簡単な言葉と例で説明できますか?

私はまた、Google の #1 ヒットのトピックJava Tip: When to use ForkJoinPool vs ExecutorService from javaworld.comを読みましたが、この記事ではタイトルの質問に答えていません。

この forkjoin プールをテストしようとしていますが、うまくいきません。なぜだろう？

これは、配列を取得し、その要素に 3 を追加するために作成したクラスです。

これがメインクラスです：