[英]Memory performance/cache puzzle
我有一个记忆表现难题。 我正在尝试确定从主内存中获取字节需要花费多长时间,以及各种BIOS设置和内存硬件参数如何影响它。 我为Windows编写了以下代码,该代码在循环中通过读取另一个缓冲区刷新高速缓存,然后一次一次以不同的步长读取单个字节的目标缓冲区。 我认为,一旦跨度是缓存行大小,这就是我要测量的数量,因为每次读取都会进入主内存。 这是基准代码(请注意,缓冲区的大小为跨度x 1MB,并且我将线程固定到核心1):
#include <stdio.h>
#include <memory.h>
#define NREAD (1024*1024)
#define CACHE_SIZE (50*1024*1024)
char readTest(int stride) {
LARGE_INTEGER frequency;
LARGE_INTEGER start;
LARGE_INTEGER end;
int rep, i,ofs;
double time, min_time=1e100, max_time=0.0, mean_time=0.0;
char *buf = (char *)malloc(NREAD*stride);
char *flusher = (char *)malloc(CACHE_SIZE);
char jnk=0;
for(rep=0; rep<255; rep++) {
// read the flusher to flush the cache
for(ofs = 0; ofs<CACHE_SIZE; ofs+=64) jnk+=flusher[ofs];
if (QueryPerformanceFrequency(&frequency) == FALSE) exit(-1);
if (QueryPerformanceCounter(&start) == FALSE) exit(-2);
// here's the timed loop
for(ofs=0; ofs<NREAD*stride; ofs+=stride) jnk += buf[ofs];
if (QueryPerformanceCounter(&end) == FALSE) exit(-3);
time = (double)(end.QuadPart - start.QuadPart) / (double)frequency.QuadPart*1e6;
max_time = time > max_time ? time : max_time;
min_time = time < min_time ? time : min_time;
mean_time += time;
}
mean_time /= 255;
printf("Stride = %4i, Max: %6.0f us, Min: %6.0f us, Mean: %6.0f us, B/W: %4.0f MB/s\n", stride, max_time, min_time, mean_time, NREAD/min_time);
free(buf);
free(flusher);
return jnk;
}
int main(int argc, char* argv[]) {
SetThreadAffinityMask(GetCurrentThread(), 1); // pin to core 1 to avoid weirdness
// run the tests
readTest(1); readTest(2); readTest(4); readTest(6); readTest(8);
readTest(12); readTest(16); readTest(24); readTest(32); readTest(48);
readTest(64); readTest(96); readTest(128); readTest(192); readTest(256);
readTest(384); readTest(512); readTest(768); readTest(1024); readTest(1536);
return 0;
}
定时的内部循环组装为:
// here's the timed loop
for(ofs=0; ofs<NREAD*stride; ofs+=stride) jnk += buf[ofs];
00F410AF xor eax,eax
00F410B1 test edi,edi
00F410B3 jle readTest+0C2h (0F410C2h)
00F410B5 mov edx,dword ptr [buf]
00F410B8 add bl,byte ptr [eax+edx]
00F410BB add eax,dword ptr [stride]
00F410BE cmp eax,edi
00F410C0 jl readTest+0B5h (0F410B5h)
我在双处理器E5-2609机器上运行了此命令,结果如下:
Stride = 1, Max: 2362 us, Min: 937 us, Mean: 950 us, B/W: 1119 MB/s
Stride = 2, Max: 1389 us, Min: 968 us, Mean: 978 us, B/W: 1083 MB/s
Stride = 4, Max: 1694 us, Min: 1026 us, Mean: 1037 us, B/W: 1022 MB/s
Stride = 6, Max: 2418 us, Min: 1098 us, Mean: 1124 us, B/W: 955 MB/s
Stride = 8, Max: 2835 us, Min: 1234 us, Mean: 1252 us, B/W: 850 MB/s
Stride = 12, Max: 4203 us, Min: 1527 us, Mean: 1559 us, B/W: 687 MB/s
Stride = 16, Max: 5130 us, Min: 1816 us, Mean: 1849 us, B/W: 577 MB/s
Stride = 24, Max: 7370 us, Min: 2408 us, Mean: 2449 us, B/W: 435 MB/s
Stride = 32, Max: 10039 us, Min: 2901 us, Mean: 3014 us, B/W: 361 MB/s
Stride = 48, Max: 14248 us, Min: 4652 us, Mean: 4731 us, B/W: 225 MB/s
Stride = 64, Max: 19149 us, Min: 6340 us, Mean: 6447 us, B/W: 165 MB/s
Stride = 96, Max: 28848 us, Min: 8475 us, Mean: 8615 us, B/W: 124 MB/s
Stride = 128, Max: 37449 us, Min: 9900 us, Mean: 10160 us, B/W: 106 MB/s
Stride = 192, Max: 51718 us, Min: 11282 us, Mean: 11563 us, B/W: 93 MB/s
Stride = 256, Max: 62193 us, Min: 11558 us, Mean: 11924 us, B/W: 91 MB/s
Stride = 384, Max: 86943 us, Min: 11829 us, Mean: 12260 us, B/W: 89 MB/s
Stride = 512, Max: 108661 us, Min: 11847 us, Mean: 12401 us, B/W: 89 MB/s
Stride = 768, Max: 167951 us, Min: 11797 us, Mean: 12946 us, B/W: 89 MB/s
Stride = 1024, Max: 211700 us, Min: 12893 us, Mean: 13979 us, B/W: 81 MB/s
Stride = 1536, Max: 332214 us, Min: 12967 us, Mean: 15077 us, B/W: 81 MB/s
这是我的问题:
高速缓存行不是跟踪内存的唯一粒度。 从虚拟地址到物理地址的转换发生在页面粒度上。 您的系统几乎可以肯定使用4k页面。
步伐为64,每页可获得64个条目,因此您有16384页。 L2 TLB只能跟踪那些页面中的512,因此您在每个新页面上都会遇到L2 TLB丢失(每第64次访问)。
跨度为1024时,每页有4个条目,因此,您有262144页。 现在,您在第4次访问时会遇到L2 TLB丢失。
tl; dr:TLB的失误正在杀死您。 您可以使用性能计数器直接观察此情况,而不必让Stack Overflow为您读取茶叶。 您还可以使系统使用一个或多个“超级页面”来分配缓冲区,以扩展TLB的范围(尽管不同的系统对此功能的支持程度不同)。
由于预取而导致行大小下降之后,性能会继续下降-只要您稳定地跨过缓存行(甚至跨步),您就可以享受HW预取器带来的接下来几行的好处。 L2流媒体特别有用,因为它比访问流运行得更快。
但是,一旦跨度超过128字节,就应该在流预取器之前开始运行,这将导致每次访问的全部延迟。
为确保确实如此-禁用预取(希望您的系统在BIOS中允许这样做)编辑:Stephen也提出了关于访问TLB查找的比率的一个很好的观点-这将占很大的步伐。 如果您绘制每个跨步的时间,我愿意打赌,由于TLB的未命中率,您会看到一个强劲的趋势,最重要的是在64字节和128字节的跨步之间跳跃。
我相信您的第一次迭代会由于TLB冷而变长。 您可以通过尝试刷新(硬..)或运行预热迭代并仅从第二个开始进行测量来对此进行测试。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.