我受到这个问题的启发，写了一个简单的程序来测试我的机器在每个缓存级别的内存带宽:
Why vectorizing the loop does not have performance improvement
我的代码使用 memset 反复写入缓冲区(或多个缓冲区)并测量速度。它还保存每个缓冲区的地址以在最后打印。这是 list :
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
#define SIZE_KB {8, 16, 24, 28, 32, 36, 40, 48, 64, 128, 256, 384, 512, 768, 1024, 1025, 2048, 4096, 8192, 16384, 200000}
#define TESTMEM 10000000000 // Approximate, in bytes
#define BUFFERS 1
double timer(void)
{
struct timeval ts;
double ans;
gettimeofday(&ts, NULL);
ans = ts.tv_sec + ts.tv_usec*1.0e-6;
return ans;
}
int main(int argc, char **argv)
{
double *x[BUFFERS];
double t1, t2;
int kbsizes[] = SIZE_KB;
double bandwidth[sizeof(kbsizes)/sizeof(int)];
int iterations[sizeof(kbsizes)/sizeof(int)];
double *address[sizeof(kbsizes)/sizeof(int)][BUFFERS];
int i, j, k;
for (k = 0; k < sizeof(kbsizes)/sizeof(int); k++)
iterations[k] = TESTMEM/(kbsizes[k]*1024);
for (k = 0; k < sizeof(kbsizes)/sizeof(int); k++)
{
// Allocate
for (j = 0; j < BUFFERS; j++)
{
x[j] = (double *) malloc(kbsizes[k]*1024);
address[k][j] = x[j];
memset(x[j], 0, kbsizes[k]*1024);
}
// Measure
t1 = timer();
for (i = 0; i < iterations[k]; i++)
{
for (j = 0; j < BUFFERS; j++)
memset(x[j], 0xff, kbsizes[k]*1024);
}
t2 = timer();
bandwidth[k] = (BUFFERS*kbsizes[k]*iterations[k])/1024.0/1024.0/(t2-t1);
// Free
for (j = 0; j < BUFFERS; j++)
free(x[j]);
}
printf("TESTMEM = %ld\n", TESTMEM);
printf("BUFFERS = %d\n", BUFFERS);
printf("Size (kB)\tBandwidth (GB/s)\tIterations\tAddresses\n");
for (k = 0; k < sizeof(kbsizes)/sizeof(int); k++)
{
printf("%7d\t\t%.2f\t\t\t%d\t\t%x", kbsizes[k], bandwidth[k], iterations[k], address[k][0]);
for (j = 1; j < BUFFERS; j++)
printf(", %x", address[k][j]);
printf("\n");
}
return 0;
}
结果(BUFFERS = 1):
TESTMEM = 10000000000
BUFFERS = 1
Size (kB) Bandwidth (GB/s) Iterations Addresses
8 52.79 1220703 90b010
16 56.48 610351 90b010
24 57.01 406901 90b010
28 57.13 348772 90b010
32 45.40 305175 90b010
36 38.11 271267 90b010
40 38.02 244140 90b010
48 38.12 203450 90b010
64 37.51 152587 90b010
128 36.89 76293 90b010
256 35.58 38146 d760f010
384 31.01 25431 d75ef010
512 26.79 19073 d75cf010
768 26.20 12715 d758f010
1024 26.20 9536 d754f010
1025 18.30 9527 90b010
2048 18.29 4768 d744f010
4096 18.29 2384 d724f010
8192 18.31 1192 d6e4f010
16384 18.31 596 d664f010
200000 18.32 48 cb2ff010
我可以很容易地看到 32K L1 缓存和 256K L2 缓存的效果。我不明白的是为什么memset缓冲区大小超过1M后性能突然下降。我的 L3 缓存应该是 8M。它也发生得太突然了，完全没有像 L1 和 L2 缓存大小超出时那样逐渐减少。
我的处理器是 Intel i7 3700。来自/sys/devices/system/cpu/cpu0/cache 的 L3 缓存的详细信息是:
level = 3
coherency_line_size = 64
number_of_sets = 8192
physical_line_partition = 1
shared_cpu_list = 0-7
shared_cpu_map = ff
size = 8192K
type = Unified
ways_of_associativity = 16
我想我会尝试使用多个缓冲区 - 在每个 1M 的 2 个缓冲区上调用 memset，看看性能是否会下降。 BUFFERS = 2，我得到:
TESTMEM = 10000000000
BUFFERS = 2
Size (kB) Bandwidth (GB/s) Iterations Addresses
8 54.15 1220703 e59010, e5b020
16 51.52 610351 e59010, e5d020
24 38.94 406901 e59010, e5f020
28 38.53 348772 e59010, e60020
32 38.31 305175 e59010, e61020
36 38.29 271267 e59010, e62020
40 38.29 244140 e59010, e63020
48 37.46 203450 e59010, e65020
64 36.93 152587 e59010, e69020
128 35.67 76293 e59010, 63769010
256 27.21 38146 63724010, 636e3010
384 26.26 25431 63704010, 636a3010
512 26.19 19073 636e4010, 63663010
768 26.20 12715 636a4010, 635e3010
1024 26.16 9536 63664010, 63563010
1025 18.29 9527 e59010, f59420
2048 18.23 4768 63564010, 63363010
4096 18.27 2384 63364010, 62f63010
8192 18.29 1192 62f64010, 62763010
16384 18.31 596 62764010, 61763010
200000 18.31 48 57414010, 4b0c3010
似乎两个 1M 缓冲区都保留在 L3 缓存中。但是尝试稍微增加任一缓冲区的大小，性能就会下降。
我一直在使用 -O3 进行编译。它并没有太大的区别(除了可能在 BUFFERS 上展开循环)。我尝试使用 -O0 并且除了 L1 速度之外它是相同的。 gcc 版本是 4.9.1。
总而言之，我有一个两部分的问题:
- 为什么我的 8 MB 三级缓存对大于 1M 的内存块没有任何好处？
- 为什么性能下降如此突然？
编辑:
根据 Gabriel Southern 的建议，我使用 perf 运行我的代码，使用 BUFFERS=1 一次只有一个缓冲区大小。这是完整的命令:
perf stat -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses -r 100 ./a.out 2> perfout.txt
-r 表示 perf 将运行 a.out 100 次并返回平均统计信息。
perf的输出，带有#define SIZE_KB {1024}:
Performance counter stats for './a.out' (100 runs):
1,508,798 dTLB-loads ( +- 0.02% )
0 dTLB-load-misses # 0.00% of all dTLB cache hits
625,967,550 dTLB-stores ( +- 0.00% )
1,503 dTLB-store-misses ( +- 0.79% )
0.360471583 seconds time elapsed ( +- 0.79% )
并使用 #define SIZE_KB {1025}:
Performance counter stats for './a.out' (100 runs):
1,670,402 dTLB-loads ( +- 0.09% )
0 dTLB-load-misses # 0.00% of all dTLB cache hits
626,099,850 dTLB-stores ( +- 0.00% )
2,115 dTLB-store-misses ( +- 2.19% )
0.503913416 seconds time elapsed ( +- 0.06% )
因此，1025K 缓冲区似乎确实有更多的 TLB 未命中。但是，使用这个大小的缓冲区，程序会执行大约 9500 次 memset 调用，因此每次 memset 调用的未命中率仍然不到 1 次。
最佳答案
简答:
您的 memset 版本在初始化大于 1 MB 的内存区域时开始使用非临时存储。因此，即使您的 L3 缓存大于 1 MB，CPU 也不会将这些行存储在其缓存中。因此，对于大于 1 MB 的缓冲区值，性能受到系统中可用内存带宽的限制。
详情:
背景:
我在几个不同的系统上测试了您提供的代码，最初专注于研究 TLB，因为我认为在 2 级 TLB 中可能会出现抖动。然而，我收集的数据都没有证实这个假设。
我测试的一些系统使用了带有最新版本 glibc 的 Arch Linux，而其他系统使用了使用旧版本 eglibc 的 Ubuntu 10.04。在使用多个不同的 CPU 架构进行测试时，当使用静态链接的二进制文件时，我能够重现问题中描述的行为。我关注的行为是 SIZE_KB 为 1024 和 1025 时的运行时显着差异。性能差异的原因是针对慢速和快速版本执行的代码发生了变化。
汇编代码
我使用 perf record 和 perf annotate 来收集执行汇编代码的踪迹，以查看热代码路径是什么。代码如下所示，格式如下:
执行指令的时间百分比 |地址 |指令。
我已经从省略了大部分地址的较短版本中复制了热循环，并且有一条连接回环边缘和循环头的线。
对于在 Arch Linux 上编译的版本，热循环是(对于 1024 和 1025 大小):
2.35 │a0:┌─+movdqa %xmm8,(%rcx)
54.90 │ │ movdqa %xmm8,0x10(%rcx)
32.85 │ │ movdqa %xmm8,0x20(%rcx)
1.73 │ │ movdqa %xmm8,0x30(%rcx)
8.11 │ │ add $0x40,%rcx
0.03 │ │ cmp %rcx,%rdx
│ └──jne a0
对于 Ubuntu 10.04 二进制文件，以 1024 大小运行时的热循环为:
│a00:┌─+lea -0x80(%r8),%r8
0.01 │ │ cmp $0x80,%r8
5.33 │ │ movdqa %xmm0,(%rdi)
4.67 │ │ movdqa %xmm0,0x10(%rdi)
6.69 │ │ movdqa %xmm0,0x20(%rdi)
31.23 │ │ movdqa %xmm0,0x30(%rdi)
18.35 │ │ movdqa %xmm0,0x40(%rdi)
0.27 │ │ movdqa %xmm0,0x50(%rdi)
3.24 │ │ movdqa %xmm0,0x60(%rdi)
16.36 │ │ movdqa %xmm0,0x70(%rdi)
13.76 │ │ lea 0x80(%rdi),%rdi
│ └──jge a00
对于缓冲区大小为 1025 的 Ubuntu 10.04 版本，热循环为:
│a60:┌─+lea -0x80(%r8),%r8
0.15 │ │ cmp $0x80,%r8
1.36 │ │ movntd %xmm0,(%rdi)
0.24 │ │ movntd %xmm0,0x10(%rdi)
1.49 │ │ movntd %xmm0,0x20(%rdi)
44.89 │ │ movntd %xmm0,0x30(%rdi)
5.46 │ │ movntd %xmm0,0x40(%rdi)
0.02 │ │ movntd %xmm0,0x50(%rdi)
0.74 │ │ movntd %xmm0,0x60(%rdi)
40.14 │ │ movntd %xmm0,0x70(%rdi)
5.50 │ │ lea 0x80(%rdi),%rdi
│ └──jge a60
这里的主要区别在于，较慢的版本使用 movntd 指令，而较快的版本使用 movdqa 指令。英特尔软件开发人员手册对非临时存储有以下说明:
For WC memory type in particular, the processor never appears to read the data into the cache hierarchy. Instead, the non-temporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache.
所以这似乎解释了使用大于 1 MB 的值的 memset 不适合缓存的行为。下一个问题是为什么 Ubuntu 10.04 系统和 Arch Linux 系统之间存在差异，为什么选择 1 MB 作为分界点。为了调查这个问题，我查看了 glibc 源代码:
memset的源代码
查看 sysdeps/x86_64/memset.S 上的 glibc git 存储库，我发现有趣的第一个提交是 b2b671b677d92429a3d41bf451668f476aa267ed
提交说明是:
Faster memset on x64
This implementation speed up memset in several ways. First is avoiding expensive computed jump. Second is using fact that arguments of memset are most of time aligned to 8 bytes.
Benchmark results on: kam.mff.cuni.cz/~ondra/benchmark_string/memset_profile_result27_04_13.tar.bz2
还有 website referenced有一些有趣的分析数据。
diff of the commit表明 memset 的代码被简化了很多，并且删除了非临时存储。这与来自 Arch Linux 的分析代码显示的内容相符。
看older code我看到是否使用非临时存储的选择似乎使用了一个描述为最大缓存大小
L(byte32sse2_pre):
mov __x86_shared_cache_size(%rip),%r9d # The largest cache size
cmp %r9,%r8
ja L(sse2_nt_move_pre)
计算的代码在:sysdeps/x86_64/cacheinfo.c
虽然看起来有计算实际共享缓存大小的代码，但默认值也是1 MB :
long int __x86_64_shared_cache_size attribute_hidden = 1024 * 1024;
所以我怀疑是否使用了默认值，但代码选择 1MB 作为截止点可能还有其他原因。
在任何一种情况下，您的问题的总体答案似乎是您系统上的 memset 版本在设置大于 1 MB 的内存区域时使用了非临时存储。
关于c++ - 为什么我的 8M L3 缓存对大于 1M 的阵列没有任何好处？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30313600/