問題タブ [fork-join]

2 つの CPU があり、fork/join フレームワークが動作するように 1000 のタスクをスケジュールする場合、タスクは一度に最大 2 つ実行されますか、それとも同じ CPU でより多くのタスクが並行して実行されますか? (たとえば、1 つのタスクが I/O を待機している場合、CPU がアイドル状態になり、別のスレッドが実行される可能性があります)

Java 7 の同時実行性と並列処理機能である Fork/Join Framework に手を染めています。

特定のパスの下にあるすべてのディレクトリのリストを表示しようとしています。これが正しいかどうか教えてもらえますか？

これが私のメインクラスです - タスクを開始する JoinForkExample

そして、これが私の実際のタスクです

私はほとんど意図した結果を得ています。しかし、これが正しいかどうかはよくわかりません。そして驚くべきことに、ジョイン/フォーク フレームワークを使用せずに同じことを実行した場合でも、実行の時間差に気付きません。

何かご意見は！

私は Scala/Akka は初めてですが、アクターベースのモデリングの概念はよく知っています。パフォーマンスを向上させるために既存のコードを並列化しようとしています。2 つのバージョンがあります。1 つは Scala/Akka で、もう 1 つは Java 7 の ForkJoinPool です。

アクターベースのアプローチの方が速いと期待していましたが、結果は逆です。Scala/Akka では 20 秒、Java fork/join では 17 秒です。

akka が本質的に遅いかどうか知りたいですか? それとも、両方の実装で通常の Java で記述された既存のコードのクラスを使用しているためでしょうか?

これは、今日の別の質問に対する回答の「副作用」として現れました。それは実際の問題よりも好奇心に関するものです。

Java SE 7は、Oracleが「フォーク/結合フレームワーク」と呼ぶものを提供します。これは、複数のプロセッサに作業をスケジュールするためのおそらく優れた方法です。それがどのように機能するかは理解していますが、それがどこで優れているのか、そして仕事を盗むことについての主張は理解できません。

たぶん、他の誰かが、なぜこのアプローチが望ましいのかについてより多くの洞察を持っているでしょう（それが派手な名前を持っているという理由以外で）。

fork / joinの基礎となるプリミティブはForkJoinTasksであり、これはFuturesであり、作業をすぐに実行するという考え方です[原文のまま]（「すぐに」という表現は、メインスレッドで同期的に発生することを意味するため、誤解を招く可能性があります。実際には、これは内部で発生します。 a Future）特定のしきい値を下回るか、しきい値に達するまで作業を2つのタスクに再帰的に分割します。

未来とは、不透明で不特定の方法で非同期的に実行されるタスクをオブジェクトにカプセル化するという概念です。結果が利用可能かどうかを確認できる関数があり、結果を（待機して）取得できる関数があります。
厳密に言えば、futureが非同期で実行されるかどうかさえわかりません。それは、内部で実行される可能性get()があります。理論的には、実装は将来ごとにスレッドを生成したり、スレッドプールを使用したりすることもできます。
実際には、Javaは、スレッドプールが接続されたタスクキューにタスクとしてfuturesを実装します（同じことがフォーク/ジョインフレームワーク全体にも当てはまります）。

フォーク/結合のドキュメントには、この具体的な使用例が示されています。

これにより、Mergesortがタスクをトラバースする方法と同じ方法で、基になるスレッドプールのタスクキューにタスクが送信されます（再帰のおかげで）。
たとえば、処理する32個の「アイテム」の配列があり、しきい値が4で、均等に分割すると、それぞれ4個の「アイテム」を持つ8つのタスクが生成され、次のようになります。

シングルコアプロセッサでは、これによりタスクグループ1-2-3-4-5-6-7-8が順番に送信/実行されます（非常に複雑な方法で）。
デュアルコアプロセッサでは、これは（1,3）-（2,4）-（5,7）-（6,8） ^[1]を送信/実行します。
クアッドコアプロセッサでは、これは（1,3,5,7）-（2,4,6,8）を送信/実行します。

それに比べて、優れた魔法がすべてない単純な実装では、タスク1-2-3-4-5-6-7-8をすぐにタスクキューに送信するだけです。いつも。

シングルコアプロセッサでは、これは1-2-3-4-5-6-7-8を送信/実行します。
デュアルコアプロセッサでは、これは（1,2）-（3,4）-（5,6）-（7,8）を送信/実行します。
クアッドコアプロセッサでは、これは（1,2,3,4）-（5,6,7,8）を送信/実行します。

質問：

1. sThresholdの連続するアイテムを1つのタスクに詰め込み、スレッドプールのタスクキューに次々にタスクを送信する代わりに、ツリーのような再帰階層が生成されます。これには、実際には何も行わないN個のサブタスクのN + log2（N）オブジェクトの構築、参照、および破棄が含まれます。なぜこれが優れているのですか？

2. 参照の局所性は保持されません。プロセッサキャッシュも仮想メモリも、そのように扱われるようなものではありません。なぜこれが優れているのですか？

3. ユニプロセッサシステムを除いて、タスクは元の順序に近い順序でスケジュールされないことが保証されています。それが本当に問題でなければ、これは問題ではないかもしれませんが、それは例えば柵や障壁のようなものをかなり実行不可能にします。フェンスのようなものを作成する唯一の方法は、ルートオブジェクトが完了するのを待ってから、新しいタスクを送信することだけです。これは、完全なパイプラインストールに相当します（これはまさにあなたが決して起こりたくないことです）。

4. Oracleのドキュメントによると、このアプローチは作業の盗用を実装しているため、スレッドプールよりも優れています。私はこれが起こっているのを見ていません。私が見ることができるのは、単純な通常のスレッドプールにタスクを送信する非常に複雑な方法です。これはどのように魔法のように仕事を盗むことを実装することになっていますか？

^[1]複雑にしすぎないようにし、ワーカースレッドが互いに追い越さないことを前提としましょう。タスクはすべて、処理に同じ時間がかかります。そうしないと、送信は同じですが、実行はもちろん異なる順序で発生する可能性があります。

私は最近、リアルタイム 3D グラフィックス アプリケーションでマルチコア プロセッサの能力をより効率的に活用することに関して、並列処理の利点に関する講義に参加しました。このディスカッションは、C++ と TBB (Threading Building Blocks) (Intel) に関するものでした。Java 7 の Fork/Join について知りましたが、OpenGL / JOGL を介してリアルタイム 3D グラフィックスを実行する方法についてもっと知りたいです。

OpenGL/JOGL は 1 つのスレッドに存在する必要があると聞いたことがあります。これが本当かどうかはわかりません。リアルタイム グラフィック アプリケーションに関して、Java での並列処理/マルチコア プログラミングの経験があり、すばらしいリソースをいくつか教えていただければ幸いです。

誰かがJDK 7のフォーク/ジョイン機能の簡単な例を提供できますか.

オラクルが提供する例を見ましたが、少し混乱しています

2 つの異なる xml を解析するために 2 つのスレッドを生成するメイン スレッドがあります。このシナリオで Java 7 fork-join を使用する必要があるのか​​、それとも jdk 1.4 で十分に使用していた従来の方法を使用する必要があるのか​​を知りたいですか?

Fork Join に実装されているスケジューリング メカニズムは、利用可能な空きコアがいつでもある場合、スレッドがそれらの空きコアで確実にスケジュールされることを必然的に伴いますか?

Java fork join を使用して再帰的な問題を解決したいのですが、再帰ステップごとに明示的に新しいタスク インスタンスを作成したくありません。その理由は、タスクが多すぎるということはオブジェクトが多すぎるということであり、数分間の処理でメモリがいっぱいになってしまうからです。

Java 6 で次のソリューションを使用していますが、Java 7 のより良い実装はありますか?

同じタスクで関数を再度呼び出すなどのことを試みinvoke()ましたが（もちろん、関連フィールドを更新した後）、うまくいかないようです。