正確に8192要素をループするとプログラムが遅くなるのはなぜですか？

これは問題のプログラムからの抜粋です。行列img[][]のサイズはSIZE×SIZEで、次のように初期化されます。

img[j][i] = 2 * j + i

次に、マトリックスを作成res[][]します。ここの各フィールドは、imgマトリックス内のその周囲の9つのフィールドの平均になります。簡単にするため、境界線は0のままにしておきます。

for(i=1;i<SIZE-1;i++) 
    for(j=1;j<SIZE-1;j++) {
        res[j][i]=0;
        for(k=-1;k<2;k++) 
            for(l=-1;l<2;l++) 
                res[j][i] += img[j+l][i+k];
        res[j][i] /= 9;
}

これでプログラムは終わりです。完全を期すために、これが以前のものです。後にコードはありません。ご覧のとおり、それは初期化です。

#define SIZE 8192
float img[SIZE][SIZE]; // input image
float res[SIZE][SIZE]; //result of mean filter
int i,j,k,l;
for(i=0;i<SIZE;i++) 
    for(j=0;j<SIZE;j++) 
        img[j][i] = (2*j+i)%8196;

基本的に、このプログラムはSIZEが2048の倍数である場合、実行時間が長くなります。

SIZE = 8191: 3.44 secs
SIZE = 8192: 7.20 secs
SIZE = 8193: 3.18 secs

コンパイラはGCCです。私が知っていることから、これはメモリ管理のためですが、私はその主題についてあまり知らないので、私はここで尋ねています。

これを修正する方法もいいですが、誰かがこれらの実行時間を説明できれば、もう十分満足しています。

私はすでにmalloc / freeを知っていますが、問題は使用されるメモリの量ではなく、単に実行時間に過ぎないため、それがどのように役立つかわかりません。

違いは、次の関連する質問と同じスーパーアライメントの問題が原因です。

• 512x512の行列の転置が、513x513の行列の転置よりもはるかに遅いのはなぜですか？
• 行列の乗算：行列のサイズの小さな違い、タイミングの大きな違い

しかし、それはコードにもう1つの問題があるためだけです。

元のループから始めます。

for(i=1;i<SIZE-1;i++) 
    for(j=1;j<SIZE-1;j++) {
        res[j][i]=0;
        for(k=-1;k<2;k++) 
            for(l=-1;l<2;l++) 
                res[j][i] += img[j+l][i+k];
        res[j][i] /= 9;
}

最初に、2つの内部ループが取るに足らないものであることに注意してください。次のように展開できます。

for(i=1;i<SIZE-1;i++) {
    for(j=1;j<SIZE-1;j++) {
        res[j][i]=0;
        res[j][i] += img[j-1][i-1];
        res[j][i] += img[j  ][i-1];
        res[j][i] += img[j+1][i-1];
        res[j][i] += img[j-1][i  ];
        res[j][i] += img[j  ][i  ];
        res[j][i] += img[j+1][i  ];
        res[j][i] += img[j-1][i+1];
        res[j][i] += img[j  ][i+1];
        res[j][i] += img[j+1][i+1];
        res[j][i] /= 9;
    }
}

これで、関心のある2つの外部ループが残ります。

これで、この質問では問題が同じであることがわかります。2D配列を反復処理するとき、ループの順序がパフォーマンスに影響するのはなぜですか？

行ごとではなく列ごとに行列を繰り返します。

この問題を解決するには、2つのループを交換する必要があります。

for(j=1;j<SIZE-1;j++) {
    for(i=1;i<SIZE-1;i++) {
        res[j][i]=0;
        res[j][i] += img[j-1][i-1];
        res[j][i] += img[j  ][i-1];
        res[j][i] += img[j+1][i-1];
        res[j][i] += img[j-1][i  ];
        res[j][i] += img[j  ][i  ];
        res[j][i] += img[j+1][i  ];
        res[j][i] += img[j-1][i+1];
        res[j][i] += img[j  ][i+1];
        res[j][i] += img[j+1][i+1];
        res[j][i] /= 9;
    }
}

これにより、すべての非順次アクセスが完全に排除されるため、2のべき乗でランダムにスローダウンすることはなくなります。

Core i7 920 @ 3.5 GHz

元のコード：

8191: 1.499 seconds
8192: 2.122 seconds
8193: 1.582 seconds

交換された外部ループ：

8191: 0.376 seconds
8192: 0.357 seconds
8193: 0.351 seconds

次のテストは、デフォルトのQt Creatorインストールで使用されるため、Visual C ++コンパイラで行われました（最適化フラグがないと思います）。GCCを使用する場合、Mysticalのバージョンと「最適化された」コードの間に大きな違いはありません。結論は、コンパイラの最適化は人間よりもマイクロ最適化をうまく処理するということです（ついに私）。残りの回答は参照用に残しておきます。

この方法で画像を処理することは効率的ではありません。1次元配列を使用することをお勧めします。すべてのピクセルの処理は1つのループで行われます。ポイントへのランダムアクセスは、以下を使用して実行できます。

pointer + (x + y*width)*(sizeOfOnePixel)

この特定のケースでは、3つのピクセルグループがそれぞれ3回使用されるため、水平方向に3つのピクセルグループの合計を計算してキャッシュすることをお勧めします。

私はいくつかのテストを行ったが、共有する価値があると思う。各結果は5つのテストの平均です。

user1615209による元のコード：

8193: 4392 ms
8192: 9570 ms

ミスティックのバージョン：

8193: 2393 ms
8192: 2190 ms

1D配列を使用した2つのパス：水平合計の最初のパス、垂直合計と平均の2番目のパス。2つのパスは3つのポインタを使用してアドレッシングを行い、次のように増分するだけです。

imgPointer1 = &avg1[0][0];
imgPointer2 = &avg1[0][SIZE];
imgPointer3 = &avg1[0][SIZE+SIZE];

for(i=SIZE;i<totalSize-SIZE;i++){
    resPointer[i]=(*(imgPointer1++)+*(imgPointer2++)+*(imgPointer3++))/9;
}

8193: 938 ms
8192: 974 ms

1D配列を使用し、次のようにアドレス指定する2つのパス：

for(i=SIZE;i<totalSize-SIZE;i++){
    resPointer[i]=(hsumPointer[i-SIZE]+hsumPointer[i]+hsumPointer[i+SIZE])/9;
}

8193: 932 ms
8192: 925 ms

ワンパスキャッシュの水平方向の合計は1行先にあるため、キャッシュにとどまります。

// Horizontal sums for the first two lines
for(i=1;i<SIZE*2;i++){
    hsumPointer[i]=imgPointer[i-1]+imgPointer[i]+imgPointer[i+1];
}
// Rest of the computation
for(;i<totalSize;i++){
    // Compute horizontal sum for next line
    hsumPointer[i]=imgPointer[i-1]+imgPointer[i]+imgPointer[i+1];
    // Final result
    resPointer[i-SIZE]=(hsumPointer[i-SIZE-SIZE]+hsumPointer[i-SIZE]+hsumPointer[i])/9;
}

8193: 599 ms
8192: 652 ms

結論：

• 複数のポインターを使用して、増分だけを使用する利点はありません（もっと高速だったと思います）
• 水平合計をキャッシュすることは、それらを数回計算するよりも優れています。
• 2パスは3倍高速ではなく、2倍のみです。
• シングルパスと中間結果のキャッシュの両方を使用すると、3.6倍速く達成することが可能です。

きっともっと良いことができると思います。

注 この回答は、Mysticalの優れた回答で説明されているキャッシュの問題ではなく、一般的なパフォーマンスの問題を対象としています。最初は、それは単なる擬似コードでした。コメントでテストを依頼されました...テスト付きの完全にリファクタリングされたバージョンです。