スケーラビリティが消えた

Question

私は、Javaの並行処理のパフォーマンスをテストするためのおもちゃプログラムを作った。私はここに置く： https://docs.google.com/open?id=0B4e6u_s5iHT6MTNkZGM5ODQtNjZmYi00NTMwLWJlMjUtYzViOWZlMDM5NGVi

これは、使用するスレッドの数を示す整数値を引数として受け取ります。このプログラムは、ある範囲の素数を計算します。一般的なバージョンは44行目から53行目のコメントで得られ、ほぼ完璧なスケーラビリティを生成します。

ただし、ローカルで単純な計算を行う44〜53行のコメントを外して、変数sを十分大きな値に調整すると、スケーラビリティが消えることがあります。

私のおもちゃプログラムが共有データを使用するかどうかは、並行性のパフォーマンスが低下する可能性があります。そして、消えたスケーラビリティを説明する方法（私はガベージコレクションのような低レベルのオーバーヘッドがそれを引き起こすと思います）？どのような解決策でもこのような問題を解決できますか？問題の

Answer 1

コードは次のとおりです。もちろん

int s = 32343; 
ArrayList<Integer> al = new ArrayList<Integer>(s); 
for (int c = 0; c < s; c++) { 
    al.add(c); 
} 
Iterator<Integer> it = al.iterator(); 
if (it.hasNext()) { 
    int c = it.next(); 
    c = c++; 
} 

あなたがsの値を増やした場合、これはあなたがリストに入れてどのように多くの事s制御するので、パフォーマンスが低下します。しかし、これは並行性やスケーラビリティとはほとんど関係がありません。数千または数百万回の捨て去り計算を行う時間を無駄にするようにコンピュータに指示するコードを書くと、もちろんパフォーマンスは低下します。 nがsに等しい、より技術的に言えば

、コードのこのセクションの時間複雑性はO(2n)である（それはリストを構築するためにn操作を要し、その後n操作はそれを反復し、それぞれの値をインクリメントします）。したがって、あなたがsを大きくするほど、このコードを実行するのに時間がかかります。

これが並行性の利点を小さくするように見える理由については、sが大きくなるにつれてメモリの影響を考慮していますか？たとえば、Javaヒープがディスクにスワップアウトされずにメモリ内のすべてを保持するのに十分な大きさであることを確認してください。何もスワップアウトされなくても、ArrayListの長さを大きくすることで、ガベージコレクタに実行時の処理（実行頻度を上げる可能性があります）が増えます。実装によっては、ガベージコレクタが実行されるたびにすべてのスレッドを一時停止している可能性があります。

スレッドごとに単一のArrayListインスタンスを割り当ててスレッドを作成した時点で、毎回新しいリストを作成するのではなくisPrime()の呼び出しでそれを再利用すれば、改善されますか？

編集：ここまでの修正版です：http://pastebin.com/6vR7Uhez

は、それは私のマシン上で次のような出力が得られます。

------------------start------------------ 
1 threads' runtimes: 
1  3766.0 
maximum: 3766.0 
main time: 3766.0 
------------------end------------------ 
------------------start------------------ 
2 threads' runtimes: 
1  897.0 
2  2483.0 
maximum: 2483.0 
main time: 2483.0 
------------------end------------------ 
------------------start------------------ 
4 threads' runtimes: 
1  576.0 
2  1473.0 
3  568.0 
4  1569.0 
maximum: 1569.0 
main time: 1569.0 
------------------end------------------ 
------------------start------------------ 
8 threads' runtimes: 
1  389.0 
2  965.0 
3  396.0 
4  956.0 
5  398.0 
6  976.0 
7  386.0 
8  933.0 
maximum: 976.0 
main time: 978.0 
------------------end------------------ 

...スレッド数を上げているとほぼリニアスケーリングを示していますアップ。私が修正した問題は、上に挙げた点とJohn Vint（今削除された）の答え、そしてConcurrentLinkedQueue構造の間違った/不必要な使用と疑わしいタイミングロジックの組み合わせだった。

我々はGCログを有効にして、両方のバージョンをプロファイルした場合、我々は元のバージョンが変更されたバージョンよりも、ガベージコレクションの実行についての10倍ほどの時間を費やしていることがわかります。

Original: [ParNew: 17401K->750K(19136K), 0.0040010 secs] 38915K->22264K(172188K), 0.0040227 secs] 
Modified: [ParNew: 17024K->0K(19136K), 0.0002879 secs] 28180K->11156K(83008K), 0.0003094 secs] 

間のように私には意味定数リスト割り当てとInteger自動ボクシングの場合、元の実装はあまりにも多くのオブジェクトを突っ込んでいたため、GCに負担がかかりすぎて、スレッドのパフォーマンスが悪くなったり、より多くのスレッドを作成します。

Javaの並行性のスケーリングがうまくいかない場合は、タスクが大小どちらであっても、どのようにメモリを使用しているのか、隠されている可能性があることに注意する必要があります落とし穴や非効率性を減らし、非効率なビットを最適化します。