16

Scala のアクターは軽量であると説明されていますが、Akka のアクターはさらに軽量であると説明されています。

だから私の質問は、アクターと並列化する価値がある作業の最小単位は何ですか (並列化できると仮定して)? レイテンシが発生する可能性がある場合、または大量の計算が必要な場合にのみ価値がありますか?

日常業務に簡単に適用できる一般的な経験則を探しています。

編集:これまでの回答で、私が興味を持っているのは、おそらく最初に尋ねた質問の逆であることに気づきました。そう:

私のプログラムをアクターで構造化することは非常に適切であり、したがって追加の開発オーバーヘッドが発生しない (または非アクター実装よりも開発オーバーヘッドが少ない) と仮定すると、実行する作業単位は非常に小さいです。どの時点でアクターを使用するとパフォーマンスが損なわれ、回避する必要がありますか?

4

3 に答える 3

6

アクターを使用するかどうかは、主に作業単位の問題ではありません。その主な利点は、並行プログラムを正しく処理しやすくすることです。これと引き換えに、別のパラダイムに従ってソリューションをモデル化する必要があります。

そのため、最初に同時実行を使用するかどうか (パフォーマンスまたは正確性が原因である可能性があります) を決定し、次にアクターを使用するかどうかを決定する必要があります。後者は好みの問題ですが、Akka 2.0 ではそうしない正当な理由が必要です。基本的に無料でオーバーヘッドがほとんどなく、分散可能性 (up & out) が得られるからです。

それでも逆の方法で決定したい場合は、パフォーマンス テストの経験則から、ターゲット メッセージ処理速度は 1 秒あたり数百万を超えないようにする必要があります。

于 2012-04-12T18:03:50.837 に答える
5

日常業務の私の経験則では、数ミリ秒かかる場合は、並列化する価値がある可能性があります。トランザクション レートはそれよりも高くなりますが (通常、オーバーヘッドは数十マイクロ秒にすぎません)、オーバーヘッドが支配的なケースは避けたいと思います。もちろん、実際に並列化する価値があるまでには、数ミリ秒よりもはるかに長い時間が必要になる場合があります。より多くのコードを書くことによってかかる時間と、それを実行することで節約される時間とのバランスを常に取る必要があります。

于 2012-04-12T15:55:20.940 に答える
0

作業単位に副作用が予想されない場合は、実行時に作業を分割することを決定することをお勧めします。

protected T compute() {
  if (r – l <= T1 || getSurplusQueuedTaskCount() >= T2)
    return problem.solve(l, r);
// decompose
}

どこ:

T1 = N / (L * Runtime.getRuntime.availableProcessors())

N - ユニット単位での作品のサイズ

L = 8..16 - 負荷係数、手動で設定

T2 = 1..3 - すべてのスティール後のワーク キューの最大長

ここに、より多くの詳細と図を含むプレゼンテーションがあります。

http://shipilev.net/pub/talks/jeeconf-May2012-forkjoin.pdf

于 2012-05-24T16:21:00.917 に答える