为什么转换512x512的矩阵要比转换513x513的矩阵慢得多?

时间:2012-07-10 13:00:21

标签: c++ performance optimization

在对不同尺寸的方形矩阵进行一些实验后,出现了一种模式。总是,转置大小为2^n的矩阵比转置大小为2^n+1 的矩阵要慢。对于较小的n值,差异不大。

但是在512的值上会出现很大的差异。(至少对我而言)

免责声明:我知道由于元素的双重交换,函数实际上并没有转置矩阵,但它没有区别。

遵循以下代码:

#define SAMPLES 1000
#define MATSIZE 512

#include <time.h>
#include <iostream>
int mat[MATSIZE][MATSIZE];

void transpose()
{
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < MATSIZE ; j++ )
   {
       int aux = mat[i][j];
       mat[i][j] = mat[j][i];
       mat[j][i] = aux;
   }
}

int main()
{
   //initialize matrix
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < MATSIZE ; j++ )
       mat[i][j] = i+j;

   int t = clock();
   for ( int i = 0 ; i < SAMPLES ; i++ )
       transpose();
   int elapsed = clock() - t;

   std::cout << "Average for a matrix of " << MATSIZE << ": " << elapsed / SAMPLES;
}

更改MATSIZE让我们改变大小(呃!)。我在ideone上发布了两个版本:

在我的环境中(MSVS 2010,完全优化),差异是相似的:

  • 尺寸512 - 平均 2.19 ms
  • 尺寸513 - 平均 0.57 ms

为什么会这样?

3 个答案:

答案 0 :(得分:180)

解释来自Optimizing software in C++中的Agner Fog,它减少了数据访问和存储在缓存中的方式。

有关条款和详细信息,请参阅wiki entry on caching,我将在此处缩小范围。

缓存按组织。一次只使用一组,其中可以使用其中包含的任何行。行的内存可以镜像行数乘以我们的缓存大小。

对于特定的内存地址,我们可以使用以下公式计算哪个集合应该反映它:

set = ( address / lineSize ) % numberOfsets

这种公式理想地在整个集合中提供均匀分布,因为每个内存地址都可能被读取(我说理想)。

很明显,可能会发生重叠。在高速缓存未命中的情况下,在高速缓存中读取存储器并替换旧值。请记住,每个集合都有许多行,其中最近最少使用的行会被新读取的内存覆盖。

我会尝试在某种程度上遵循Agner的例子:

假设每组有4行,每行包含64个字节。我们首先尝试读取地址0x2710,该地址位于集合28中。然后我们还尝试阅读地址0x2F000x37000x3F000x4700。所有这些都属于同一套。在阅读0x4700之前,集合中的所有行都将被占用。读取该内存将驱逐集合中的现有行,即最初持有0x2710的行。问题在于我们读取的地址(对于此示例)0x800分开。这是关键步幅(再次,对于此示例)。

也可以计算出临界步幅:

criticalStride = numberOfSets * lineSize

对于相同的缓存行间隔criticalStride或多个间隔的变量争用。

这是理论部分。接下来,解释(也是Agner,我正密切关注以避免犯错误):

假设一个64x64的矩阵(请记住,效果因缓存而异),缓存为8kb,每组4行* 64字节的行大小。每行可以容纳矩阵中的8个元素(64位int)。

关键步幅为2048字节,对应于矩阵的4行(在存储器中是连续的)。

假设我们正在处理第28行。我们正在尝试获取该行的元素并将它们与第28列中的元素交换。该行的前8个元素组成一个缓存行,但它们将会去记住,临界步幅是4行(列中的4个连续元素)。

当列中到达元素16时(每组4个高速缓存行和4行=故障),ex-0元素将从高速缓存中逐出。当我们到达列的末尾时,所有先前的高速缓存行都将丢失,并且在访问下一个元素时需要重新加载(整行被覆盖)。

大小不是关键步幅的倍数会让这个完美的场景更加困难,因为我们不再处理在垂直方向上分离得很重要的元素,所以缓存重新加载的数量严重减少。

另一个免责声明 - 我只是理解了解释并希望我把它钉在上面,但我可能会弄错。无论如何,我正在等待来自Mysticial的回复(或确认)。 :)

答案 1 :(得分:72)

Luchian给出了为什么这种行为发生的解释,但我认为为这个问题展示一个可能的解决方案并同时展示一些缓存遗忘算法是一个好主意

您的算法基本上可以:

for (int i = 0; i < N; i++) 
   for (int j = 0; j < N; j++) 
        A[j][i] = A[i][j];

这对现代CPU来说太可怕了。一种解决方案是了解有关缓存系统的详细信息并调整算法以避免这些问题。只要您了解这些细节,效果就会很好......不是特别便携。

我们能做得更好吗?是的,我们可以:这个问题的一般方法是cache oblivious algorithms,正如名称所说,避免依赖于特定的缓存大小[1]

解决方案如下所示:

void recursiveTranspose(int i0, int i1, int j0, int j1) {
    int di = i1 - i0, dj = j1 - j0;
    const int LEAFSIZE = 32; // well ok caching still affects this one here
    if (di >= dj && di > LEAFSIZE) {
        int im = (i0 + i1) / 2;
        recursiveTranspose(i0, im, j0, j1);
        recursiveTranspose(im, i1, j0, j1);
    } else if (dj > LEAFSIZE) {
        int jm = (j0 + j1) / 2;
        recursiveTranspose(i0, i1, j0, jm);
        recursiveTranspose(i0, i1, jm, j1);
    } else {
    for (int i = i0; i < i1; i++ )
        for (int j = j0; j < j1; j++ )
            mat[j][i] = mat[i][j];
    }
}

略微复杂,但是一个简短的测试在我的古老的e8400上展示了一些非常有趣的东西,VS2010 x64版本,MATSIZE 8192的测试代码

int main() {
    LARGE_INTEGER start, end, freq;
    QueryPerformanceFrequency(&freq);
    QueryPerformanceCounter(&start);
    recursiveTranspose(0, MATSIZE, 0, MATSIZE);
    QueryPerformanceCounter(&end);
    printf("recursive: %.2fms\n", (end.QuadPart - start.QuadPart) / (double(freq.QuadPart) / 1000));

    QueryPerformanceCounter(&start);
    transpose();
    QueryPerformanceCounter(&end);
    printf("iterative: %.2fms\n", (end.QuadPart - start.QuadPart) / (double(freq.QuadPart) / 1000));
    return 0;
}

results: 
recursive: 480.58ms
iterative: 3678.46ms

编辑:关于大小的影响:虽然在某种程度上仍然很明显,但它更不明显,这是因为我们将迭代解决方案用作叶子节点而不是递归到1(通常的递归算法优化) 。如果我们设置LEAFSIZE = 1,则缓存对我没有影响[8193: 1214.06; 8192: 1171.62ms, 8191: 1351.07ms - 在误差范围内,波动在100ms区域内;如果我们想要完全准确的价值,那么这个“基准”并不是我太舒服的事情。)

[1]这些东西的来源:好吧,如果你不能从与Leiserson合作的人那里得到一个演讲,那么我认为他们的论文是一个很好的起点。这些算法仍然很少被描述 - CLR有一个关于它们的脚注。仍然是让人们大吃一惊的绝佳方式。


编辑(注意:我不是发布此答案的人;我只想添加此内容):
这是上述代码的完整C ++版本:

template<class InIt, class OutIt>
void transpose(InIt const input, OutIt const output,
    size_t const rows, size_t const columns,
    size_t const r1 = 0, size_t const c1 = 0,
    size_t r2 = ~(size_t) 0, size_t c2 = ~(size_t) 0,
    size_t const leaf = 0x20)
{
    if (!~c2) { c2 = columns - c1; }
    if (!~r2) { r2 = rows - r1; }
    size_t const di = r2 - r1, dj = c2 - c1;
    if (di >= dj && di > leaf)
    {
        transpose(input, output, rows, columns, r1, c1, (r1 + r2) / 2, c2);
        transpose(input, output, rows, columns, (r1 + r2) / 2, c1, r2, c2);
    }
    else if (dj > leaf)
    {
        transpose(input, output, rows, columns, r1, c1, r2, (c1 + c2) / 2);
        transpose(input, output, rows, columns, r1, (c1 + c2) / 2, r2, c2);
    }
    else
    {
        for (ptrdiff_t i1 = (ptrdiff_t) r1, i2 = (ptrdiff_t) (i1 * columns);
            i1 < (ptrdiff_t) r2; ++i1, i2 += (ptrdiff_t) columns)
        {
            for (ptrdiff_t j1 = (ptrdiff_t) c1, j2 = (ptrdiff_t) (j1 * rows);
                j1 < (ptrdiff_t) c2; ++j1, j2 += (ptrdiff_t) rows)
            {
                output[j2 + i1] = input[i2 + j1];
            }
        }
    }
}

答案 2 :(得分:43)

作为Luchian Grigore's answer中解释的说明,下面是64x64和65x65矩阵的两种情况下矩阵缓存的存在情况(有关数字的详细信息,请参阅上面的链接)。

以下动画中的颜色表示以下内容:

  • white - 不在缓存中,
  • light-green - 在缓存中,
  • bright green - 缓存命中,
  • orange - 只需从RAM中读取,
  • red - 缓存未命中。

64x64案例:

cache presence animation for 64x64 matrix

注意几乎每个对新行的访问都会导致缓存未命中。现在它如何寻找正常情况,一个65x65矩阵:

cache presence animation for 65x65 matrix

在这里,您可以看到初始预热后的大多数访问都是缓存命中。这就是CPU缓存的一般工作方式。