关于c ++：为什么我的程序在完全循环8192个元素时会变慢？

Why is my program slow when looping over exactly 8192 elements?

以下是有关程序的摘录。矩阵img[][]具有大小×大小，初始化为：

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

然后，你做一个矩阵res[][]，这里的每个字段都是img矩阵中围绕它的9个字段的平均值。为了简单起见，边框保留为0。

1
2
3
4
5
6
7
8

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;
}

这就是节目的全部内容。为了完整起见，下面是前面的内容。后面没有代码。如您所见，这只是初始化。

1
2
3
4
5
6
7

#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;

基本上，当大小是2048的倍数时，此程序速度较慢，例如执行时间：

1
2
3

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

编译器是gcc。据我所知，这是因为记忆管理，但我对那个主题不太了解，这就是我在这里问的原因。

另外，如何解决这个问题也很好，但是如果有人能解释这些执行时间，我已经很高兴了。

我已经知道malloc/free，但问题不在于使用的内存量，而在于执行时间，所以我不知道这有什么帮助。

相关讨论

现在我再次查看代码，它看起来像一个图像模糊操作。它是相邻细胞的平均强度。
我还要注意，展开内部循环对性能没有影响。编译器可能会自动执行。我展开它们的唯一目的是去掉它们，以便更容易地发现外环的问题。
尽管这是正确的答案，但我还是觉得有些事情不对劲…外部/第一个索引不应该是"i"而内部索引应该是"j"吗？整个问题可以通过切换原始问题中的索引来解决，因为OP首先循环"i"。
另外，您不应该展开循环，而应该对其进行注释。尽管您注意到了，但从视觉上看，展开仍然是修复的重要部分。
@是的，我同意。i应先于j。但是当我测试它时，只需拖放for循环，而不必更改所有的索引，这对我来说就更容易了。至于循环展开。我测试过它，它在VS2010中没有任何区别。但消除它可能会使编译器优化所有代码。
通过缓存每行的和，可以将代码加速三倍。但这和其他优化都超出了原始问题的范围。
如果第二个循环比第一个循环更有效，那么我就不想再使用C++了。
@点击投票这实际上是一个硬件(缓存)问题。这与语言无关。如果您尝试用任何其他语言编译或JIT到本机代码，您可能会看到相同的效果。
@Markcanlas：我怀疑三个因素，通过缓存，您需要更多的内存，并且可能会发生交换/缓存未命中，所以我认为它需要测试。
@神秘的，我很高兴我的字节码JVM，如果它意味着我不必写第二个循环那样难看的代码。
@点击投票：你似乎被误导了。"第二个循环"只是用手神秘地展开内部循环。这是您的编译器几乎肯定会做的事情，而Mystical只是为了使外部循环的问题更加明显。这绝对不是你该做的事。
实际上，直到展开内部循环之后，我才注意到外部循环的问题。从4个筑巢层次来看，这一点都不明显。这很有趣，因为循环展开通常会使代码更不可读。但在这种情况下，它让我看到了问题所在。
说句公道话，如果CelkUpDoupe比C语言更高级，如果它优化了像你这样的问题，例如，如果它是功能性的，并且你只指定了你想要做的一个矩阵，并且让编译器整理出循环发生的细节(并且可能是并行化)，那么它可能会受益于C++。所以原因是硬件，但他很可能从软件中获益。
@泰德：三的因素不是推测性的，我是计时的。不缓存数组的整个副本，只缓存最近两行的总和。
这是一个很好的答案的完美例子：引用类似的问题，逐步解释如何处理它，解释问题，解释如何解决问题，具有很好的格式，甚至是在您的机器上运行的代码的一个例子。谢谢你的贡献。
@EricPostischil：有趣的是，没有最后两行的数据在没有缓存的情况下填充缓存，而没有缓存的情况下仍然适合，而出现缓存未命中的情况，那么就没有大小了？(我们不再考虑联合问题，而是缓存大小问题)。我仍然发现三的因素令人印象深刻，因为你也有循环和除数，在三个加法块，你可以从中删除两个额外的加法。如果我没有弄错，您仍然需要9中的5个添加项(3个用于非缓存行+2个来自缓存的添加项)，+对缓存行的额外写入。
"你怎么ericpostpischil：除了索引缓存行吗？你可以做previousRow[i]和RowBeforePreviousRow[i]自本会需要你的内容到移动previousRow[i]RowBeforePreviousRow[i]模索引？我真的很感兴趣。如果你可以看到修改后的代码信息，请。
检查我的答案"旁边的泰德。它并不是问题，但地址缓存的性能。
"ericpostpischil技术应用，这是在一个两维的场是足够窄以获得第一个专利：我4811414。这是回到A几乎什么时候25 MHz处理器。
i实施在Java和类似的测试时间的增加是由第noticeable：1.3当迭代列，当迭代by rows 0.3页。问题的大小是4096元素是一个2年的笔记本电脑。

下面的测试是用Visual C++编译器完成的，因为默认的QT创建者安装使用它(我猜没有优化标志)。当使用gcc时，Mystical的版本和我的"优化"代码之间没有很大的区别。因此，得出的结论是编译器优化比人类(最终是我)更好地处理微观优化。我把剩下的答案留作参考。

用这种方法处理图像是不有效的。最好使用一维数组。处理所有像素是在一个循环中完成的。可以使用以下方法随机访问点：

1	pointer + (x + ywidth)(sizeOfOnePixel)

在这种特殊情况下，最好水平计算和缓存三个像素组的总和，因为每个像素组使用三次。

我做了一些测试，我认为值得分享。每个结果平均为五次测试。

用户原始代码1615209：

1 2	8193: 4392 ms 8192: 9570 ms

神秘版：

1 2	8193: 2393 ms 8192: 2190 ms

使用一维数组进行两次传递：第一次传递用于水平和，第二次传递用于垂直和平均。带三个指针的二通寻址，仅按如下方式递增：

1
2
3
4
5
6
7
8
9
10

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

使用一个一维数组并按如下方式寻址的两次传递：

1
2
3
4
5
6

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
2
3
4
5
6
7
8
9
10
11
12
13
14

// 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

结论：

使用多个指针和增量没有任何好处(我以为会更快)
缓存水平和比多次计算要好。
两次传球不比三次快，只比两次快。
单次通过和缓存中间结果都可以实现3.6倍的速度

我相信可以做得更好。

注释请注意，我写这个答案是为了解决一般的性能问题，而不是Mystical优秀答案中解释的缓存问题。一开始只是伪代码。我被要求在评论中做测试…这里是一个完全重构的测试版本。