問題タブ [work-stealing]

ForkJoinPool を介して大量の画像を読み込む際に問題が発生しています。ハイパースヘディングを使用して 4 コアの Intel でテストしているため、8 つの論理スレッドがあります。ただし、プールを 4 スレッドのみに制限します。また、ImageIO で画像が見つからないというエラーが表示されます。

私が間違っていることについての洞察は素晴らしいでしょう.1700以上の画像があり、すべての画像が5MB以上の場合にのみ壊れることに気付きました.

Javaから受け取ったエラーは次のとおりです。

ファイルがそこにあることを知っているとき。このコードをガイドとして使用しました: https://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

ワークスティーリングに両端キューが必要なのはなぜですか? (例: Cilk) 所有者は上で働き、泥棒は下から盗みます。なぜ便利なのですか？

下から複数の泥棒が盗んでいる可能性があります。とにかく、ロックは必要ありませんか？大きなジョブ (たとえば、ツリーで作成されたもの) が下部に追加されることをどこかで読んだことがあります。したがって、下から盗む方が効率的です (泥棒が盗むことで忙しくなるため、コミュニケーションが少なくなります)。それですか？

ワーク スチールは、ユーザー レベル スレッドの一般的な戦略です。各プロセスには、作業を行うための作業キューがあり、他のプロセスが作業を終えたときに他のキューから盗みます。

カーネルレベルのスレッドにそのような戦略を実装するカーネルはありますか? そうでない場合、その理由は何ですか?

Linux には、スレッドを高負荷プロセッサから低負荷プロセッサに移行するカーネルレベルのスレッドにスレッド移行の概念があると思いますが、それは別のアルゴリズムのようです。しかし、私が間違っている場合は修正してください。

ありがとう

私は C++ で高性能の動的プログラムを作成しており、その結果は M × N テーブル (およそ 2000 行 × 30000 列) に配置されています。
各エントリ ( r、c ) は、テーブル内の他のいくつかの列のいくつかの行に依存します。

行rの計算をP個のプロセッサ間で並列化する最も明白な方法は、データを静的に分割することです。つまり、プロセッサpにすべての有効なkのエントリ (r, p + k P ) を計算させます。

ただし、異なる列のエントリは計算に多少異なる時間がかかります (たとえば、一方のエントリは他方のエントリの 5 倍の時間がかかる場合があります) 。早く終了する CPU は、代わりにまだ追いついている CPU から作業を盗みます。

これにアプローチする 1 つの方法は、既に計算された列の数を指定するアトミック グローバル カウンターを保持し、CPU がより多くの作業を必要とするたびにそれを増やすことです。ただし、これにより、テーブル内のすべてのエントリを計算した後、すべての CPU が同じグローバル カウンタ
にアクセスするように強制されます。つまり、プログラムがある程度シリアライズされます。各エントリの計算は多かれ少なかれ迅速なプロセスであるため、これはやや望ましくありません。

ですから、私の質問は次のとおり
です。この動的パーティショニングをよりスケーラブルな方法で実行する方法はありますか (つまり、すべてのエントリを計算した後に単一のグローバル カウンターにアクセスする必要はありません)。

Java 8 と組み合わせて使用​​される保留中のタスクのキューはありますExecutors.newWorkStealingPool()か?

たとえば、使用可能なコア数が 2 で、Executors.newWorkStealingPool()2 つのタスクが既に実行されているため空であるとします。次に、3 番目のタスクがワークスティーリング エグゼキューターに送信されるとどうなるでしょうか? キューされていますか？もしそうなら、そのキューにある場合、その境界は何ですか?

前もって感謝します。

Cilk のワーク スティール スケジューリング パフォーマンスについて説明している論文を読んでいます。

1) 私の理解では、スケジューラはクリティカル パスのタスクを認識していませんが、タスク グラフの「深く」ないタスクを盗むことによって、いずれにしてもその実行を維持しようとします。あれは正しいですか？

2) また、Cilk のワーク スチール スケジューラは、すべてのタスクが同様の複雑さであると想定していますか? タスクの複雑さが一様でない場合、スケジューラは最高のパフォーマンス、つまり最高の負荷分散を実現する上で柔軟性が低下するのではないでしょうか?

こんにちは、CompletableFuture とデフォルトForkJoinPoolで、クラシックよりもタスクの実行を最適化できると思いましたが、ExecutorService何かが欠けています

このコードでは、実行に 1 秒かかります。3 つのワーカー スレッドがあります。

OK、正常に見えます。

しかし、このコードでは 3 秒かかります。

他の待機中のタスクを起動するためにスリープ スレッドが使用されると思っていましたが、これも 1 秒かかるはずです。たとえば、IO WAINTING スレッド状態は、スレッドを他のタスクに再利用できることを意味することを読みました。この動作を でテストできますThread.sleep()か? テスト方法が間違っているのでしょうか、それとも何かを間違って理解したのでしょうか?