0

私はいくつかのパフォーマンス クリティカルな Java コードを書いています。

私は、ほぼすべての情報が、約 1000 個の整数 (ほとんどがゼロ) の変化する配列内のゼロ以外のエントリの位置から計算できるモデルを使用しています。これらの計算を減らすために、配列が変更されたときに、再計算するのではなく、一定時間内に情報を更新するアルゴリズムに取り組んでいます。これは、次のような多くのコードにつながる可能性があります

...
info1[x][y][a] = ...
info1[x][x%2+y][b] = ...
if( info3[x][y][c]!=0 )
    info2[x][y] = ...
if( some condition involving ~10 array entries) {
/** some expensive algorithm that is hopefully called rarely **/
}
info3[x][y] = ...
...

したがって、プログラムが実行しなければならない行の非常に大きな部分を構成する最小限の計算で、おそらく10回の連続した主に独立した配列書き込みが予想されます。このような単純な連続操作の数が適切であると期待する必要がありますか、または Java には、10 または 2 を実行できる速さで 20 の連続した単純な配列書き込みを実行する手段がありますか?

4

2 に答える 2

1

あなたの質問が何であるか完全に明確ではないので、いくつかの点について説明します。

  • 配列の書き込みは、配列の読み取りよりも少しだけ遅くなります。対象となる操作は、(a) 配列の境界チェック、(b) 配列インデックスの計算 (基本的には 4 の乗算 - 自明)、および実際のロード/ストアです。
  • 1 つの直線コード ブロックに複数 (「N」個) の短い配列代入ステートメントが含まれていても問題ありません。最悪の場合、単一ステートメントの N 倍の作業になります。
  • 「深い」多次元配列を持つことも大したことではありません.3次元配列がある場合、たとえば、2つの配列読み取りと1つの書き込みのように見えるストアがあります。
  • これらのすべてのシナリオで、JITC は単純な配列集中型コードを「好みます」。「一般的な」配列境界チェック、配列インデックス計算などを行う機会はたくさんあり、平凡な JITC でさえ、これをかなりうまく処理します。
  • 非常に大きな配列と実行時間の長いコードで注意する必要があることの 1 つは、特にマルチスレッドを使用している場合はメモリ フットプリントです。非常に大きな (数メガバイト) 配列に対して「まばらな」更新を行うと、多くのキャッシュ ラインと仮想メモリ ページが「ダーティ」になり、マルチスレッドの場合、キャッシュ同期 (何らかの方法で調整できた場合) が問題になる可能性があります。ボトルネック。しかし、数千の配列エントリだけでは、これは問題にはなりません。
于 2013-05-28T00:31:13.733 に答える