我受到这个问题的启发，编写了一个简单的程序来测试我的机器在每个缓存级别的内存带宽：
Why vectorizing the loop does not have performance improvement
我的代码使用memset反复写入缓冲区（或缓冲区）并测量速度。它还保存了最后打印的每个缓冲区的地址。这是列表：
#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。
总结一下，我有一个由两部分组成的问题：
根据Gabriel Southern的建议，我使用BUFFERS = 1使用perf运行我的代码，一次只有一个缓冲区大小。这是完整的命令：
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% )
所以似乎有更多的TLB未命中1025K缓冲区。但是，使用此大小缓冲区，该程序会执行大约9500次memset次呼叫，因此每memset次呼叫仍然少于1次。
答案 0 :(得分：15)
在初始化大于1 MB的内存区域时，您的memset版本开始使用非临时存储。因此，即使L3缓存大于1 MB，CPU也不会将这些行存储在其缓存中。因此，对于大于1 MB的缓冲区值，系统中的可用内存带宽会限制性能。
我测试了你在几个不同系统上提供的代码，最初专注于调查TLB，因为我认为在二级TLB中可能会出现颠簸。但是，我收集的数据都没有证实这一假设。
我测试的一些系统使用的是具有最新版glibc的Arch Linux，而其他系统使用的是使用旧版eglibc的Ubuntu 10.04。当使用多个不同的CPU架构进行测试时，我能够重现使用静态链接二进制文件时问题中描述的行为。我关注的行为是SIZE_KB 1024为1025与perf record时的运行时间差异很大。性能差异可以通过对慢速和快速版本执行的代码的更改来解释。
我使用perf annotate和percentage time executing instruction | address | instruction来收集正在执行的汇编代码的跟踪，以查看热代码路径是什么。下面的代码使用以下格式显示：
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
。
我从较短版本中复制了热循环，该版本省略了大部分地址，并且有一条连接循环后沿和循环标题的行。
对于在Arch Linux上编译的版本，热循环是（对于1024和1025大小）：
│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
对于Ubuntu 10.04二进制文件，当以1024的大小运行时，热循环是：
│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
对于运行缓冲区大小为1025的Ubuntu 10.04版本，热循环是：
movntd这里的关键区别在于较慢版本使用movdqa指令，而较快版本使用memset指令。英特尔软件开发人员手册中介绍了以下关于非临时存储的内容：
特别是对于WC内存类型，处理器似乎永远不会读取 数据进入缓存层次结构。相反，非时间提示可以 通过加载临时内部缓冲区来实现 等效的对齐缓存行而不将此数据填充到 高速缓存中。
因此，这似乎解释了使用大于1 MB的值的memset不适合缓存的行为。接下来的问题是为什么Ubuntu 10.04系统和Arch Linux系统之间存在差异，以及为什么选择1 MB作为截止点。为了调查这个问题，我查看了glibc源代码：
sysdeps/x86_64/memset.S 在memset查看glibc git repo我觉得有趣的第一个提交是b2b671b677d92429a3d41bf451668f476aa267ed
提交说明是：
x64上更快的memset
此实现以多种方式加速memset。首先是避免 昂贵的计算跳跃。其次是使用memset参数的事实 大多数时间都与8个字节对齐。
基准结果： kam.mff.cuni.cz/~ondra/benchmark_string/memset_profile_result27_04_13.tar.bz2
website referenced有一些有趣的分析数据。
diff of the commit显示The largest cache size的代码被大量简化，非临时存储被删除。这与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)
的值
long int __x86_64_shared_cache_size attribute_hidden = 1024 * 1024;
计算此代码的代码位于：sysdeps/x86_64/cacheinfo.c
虽然看起来有用于计算实际共享缓存大小的代码，但默认值也是1 MB：
memset所以我怀疑是否使用了默认值，但可能还有其他原因导致代码选择1MB作为截止点。
在任何一种情况下，您的问题的总体答案似乎是，在设置大于1 MB的内存区域时，系统上的median()版本正在使用非临时存储。
答案 1 :(得分：3)
鉴于Gabriel对生成的汇编代码的反汇编，我认为这确实是问题[编辑：他的答案已被编辑，现在它似乎是根本原因所以我们已经达成协议< / EM>]：
请注意，movnt是一个流媒体商店，可能具有（取决于确切的微架构实现）几种影响：
＃1和＃2可以改善这些操作的延迟和带宽，如果它们受内存限制，但＃3基本上强制它们受内存限制，即使它们可以适合某些缓存级别。这可能超过了好处，因为内存延迟/ BW开始时会明显更糟。
因此，你的memset库实现可能使用了错误的阈值来切换到流媒体存储版本（我想它不会检查你的LLC大小，但假设1M是内存驻留是非常奇怪的）。我建议尝试替代库，或者禁用编译器生成它们的能力（如果它支持的话）。
答案 2 :(得分：0)
你的基准测试只是写入内存，从不读取，使用memset，它可能设计得巧妙，无法从缓存到内存中读取任何内容。很可能，使用此代码，您只使用缓存内存的一半功能，与原始内存相比，没有性能提升。写入原始内存非常接近L2速度这一事实可能是一个暗示。如果L2运行速度为26 GB /秒，主内存为18 GB /秒，那么您对L3缓存的期望是什么？
您正在测量吞吐量，而不是延迟。我尝试使用基准测试，实际使用L3缓存的强度，提供比主存储器更低延迟的数据。