memory prefetch浅析
最近在用vtune分析程序性能瓶颈时，发现一些内存访问的地方竟然成了cpu热点。经过仔细分析，发现这些热点主要是对大数组非连续位置的访问的引起的。比较消耗cpu的原因应该是cache不命中。因为像这样局部性很差的内存访问逻辑，对cache是很不友好的。于是想到了prefetch……
x86（以及其他很多体系结构）的CPU提供了prefetch系列指令，用于将指定地址的内存预取到cache。如”prefetcht0 (%rax)”将以$rax所保存的值为地址的内存所在的cache line（大小一般是64byte）载入每一级cache。
在适当位置加了prefetch之后，程序里相应的cpu热点果然得以消除，程序性能得到提升。
现象
在此也写一段测试程序，体验一下prefetch的功效，并做一些简单的分析。（注，分析硬件的行为实在是一件痛苦的事情。对于软件来说，源代码摆在那里，一是一、二是二，很多问题都是确定的。而硬件不仅看不到它的具体实现，也鲜有文档。并且相比操作系统为软件提供的虚拟而单纯的运行环境，硬件环境复杂多变，有时候实在让人难以琢磨。所以以下分析实在难免存在谬误。不妥之处还请包涵。）
#include#include #include #include #include #include #include #include #include #include void usage() { printf("usage: BIN file step prefetch\n"); exit(1); } inline int calcu(int input) { #ifdef EMPTYCALC return input; #endif int val = (input % 99) * (input / 98); val = val ? val : 1; #ifdef HEAVYCALC double d = (double)input / (double)val; return (int)pow(d, 1999.9); #endif double n = sqrt(sqrt((double)(unsigned)input * 1.3)); double m = sqrt(sqrt((double)(unsigned)val * 0.9)); return (int)((double)input * (double)val * m / (n ? n : 1.1)); } int run_withprefetch(const int *array, int size, int step, int prefetch) { int result = 0; printf("run with prefetch(%d)...\n", prefetch); for (int i = 0; i < step; i++) { for (int j = i; j < size; j += step) { int k = j + step * prefetch; if (k < size) { _mm_prefetch(&array[k], _MM_HINT_T0); //const int *addr = &array[k]; //__asm__ __volatile__ ("mov (%0), %%eax"::"r"(addr):"eax"); //__asm__ __volatile__ ("mov %0, %%eax"::"r"(k):"eax"); } result += calcu(array[j]); } } return result; } int run(const int *array, int size, int step) { int result = 0; printf("run...\n"); for (int i = 0; i < step; i++) { for (int j = i; j < size; j += step) { //asm volatile("lfence"); result += calcu(array[j]); } } return result; } int main(int argc, const char *argv[]) { if (argc != 4) { usage(); } int step = atoi(argv[2]); int prefetch = atoi(argv[3]); int fd = open(argv[1], O_RDONLY); if (fd == -1) { usage(); } struct stat st; int ret = fstat(fd, &st); if (ret != 0) { usage(); } int array_size = st.st_size / sizeof(int); printf("array size: %d, step: %d. ", array_size, step); const int *array = (const int *)mmap(NULL, st.st_size, PROT_READ, MAP_POPULATE|MAP_SHARED, fd, 0); if (array == MAP_FAILED) { usage(); } struct timeval tv1, tv2; gettimeofday(&tv1, NULL); int result = 0; if (prefetch == 0) { result = run(array, array_size, step); } else if (prefetch > 0) { result = run_withprefetch(array, array_size, step, prefetch); } gettimeofday(&tv2, NULL); tv2.tv_sec -= tv1.tv_sec; tv2.tv_usec -= tv1.tv_usec; if (tv2.tv_usec < 0) { tv2.tv_usec += 1000000; tv2.tv_sec--; } printf("time cost: %d.%06d, ", tv2.tv_sec, tv2.tv_usec); printf("result: %d\n", result); return result; }
程序mmap一个大文件（由file参数指定）作为大数组，对数组中的每一个元素进行一定的变换逻辑（calc函数，通过宏定义选择三种不同复杂度的逻辑）、然后加和。
对于数组元素的访问支持顺序访问和跳跃访问（step参数，跳跃间隙）、支持预取（prefetch参数，预取提前量）。
（注意，程序最终产生的result的值只跟选择的计算逻辑和输入文件的内容相关，跟读内存的顺序无关。所以，后续不管给程序加了什么稀奇古怪的读内存逻辑，最终的result都是一致的。这就确保了我们所加的各种读内存逻辑没有引入BUG。）
一些测试结果：
$ ll -h test.tar.gz -rw-rw-r-- 1 xiangy xiangy 1.8G Jun 27 09:37 test.tar.gz $ g++ -O2 prefetch.cpp -DHEAVYCALC -o prefetch.heavy $ g++ -O2 prefetch.cpp -DEMPTYCALC -o prefetch.empty $ g++ -O2 prefetch.cpp -o prefetch.normal $ ./prefetch.normal usage: BIN file step prefetch
（选择不同复杂度的计算逻辑，编译成以不同后缀命名的可执行文件。）
[case-1]$ ./prefetch.empty test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 23.980005, result: 692002678
（空计算＋跳读内存。预期内存访问基本上都是cache miss，而计算逻辑基本上又不花时间，所以最终花费的时间主要就是读内存时间。记住这个值，下面的case经常需要参考它。）
[case-2]$ ./prefetch.normal test.tar.gz 1 0 array size: 468787200, step: 1. run... time cost: 22.846302, result: 1309150882 [case-3]$ ./prefetch.normal test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 66.041256, result: 1309150882 [case-4]$ ./prefetch.normal test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 28.247350, result: 1309150882
（以上是普通计算的运行情况。case-2顺序读内存预期基本上都是cache hit的，最终花费的时间主要是执行计算逻辑的时间；case-3跳读内存时间花费大量增加；case-4加了预取之后，时间花费基本上恢复到case-2的水平。)
[case-5]$ ./prefetch.heavy test.tar.gz 1 0 array size: 468787200, step: 1. run... time cost: 47.386533, result: 1625037789 [case-6]$ ./prefetch.heavy test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 107.783801, result: 1625037789 [case-7]$ ./prefetch.heavy test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 51.492479, result: 1625037789
（以上是复杂计算的运行情况。跟前面的表现基本一致，跳读带来了大量的时间增长，而预取又基本恢复到顺序读时的水平。)
如果读内存开销很小、或者计算开销很小，prefetch也有用么？
[case-8]$ ./prefetch.empty test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 24.253892, result: 692002678
（空计算＋跳读内存，预取效果跟不加预取时差不多。）
[case-9]$ ./prefetch.normal test.tar.gz 1 4 array size: 468787200, step: 1. run with prefetch(4)... time cost: 22.896790, result: 1309150882
（普通计算＋顺序读内存＋预取，效果跟不加预取时也差不多。）
可见当读内存存在一定开销、且开销小于或相当于计算开销时，通过适当的prefetch能够将跳读内存开销隐藏掉，基本上达到顺序读内存的效果。
反过来如果计算开销不大、或者读内存本身没什么开销，单纯想通过prefetch来提升读内存的速度，效果并不明显。
prefetch原理
为什么prefetch能达到这样的效果呢？简单来说，prefetch将原本串行工作的计算过程和读内存过程并行化了。如：
load-1 load-1
calc-1 => calc-1 load-2
load-2 calc-2 load-3
calc-2 calc-3
但是实际上却又并非如此简单。
在一个程序中，组成程序本身的指令虽然是有顺序的，但是CPU在执行指令的时候并不一定按部就班一条一条的去执行，指令之间有很多并行性可以去挖掘。（这就是所谓的ILP，Instruction Level Parallelism，指令级并行。）
两条指令想要并行执行需要满足三个条件：
1、
指令之间没有数据依赖
如：a = b * 3; c = d + 5;， 就没有依赖；
如：a = b * 3; c = a + 5; ，“写后读”依赖。第二条指令需要a的值作为输入，而a的值依赖于第一条指令的计算结果；
如：a = b * 3; a = d + 5; ，“写后写”依赖。不过虽然第二条指令一定要在第一条指令修改a的值之后才能修改a的值（确保最终a的值是d + 5的结果），但是其实两条指令是可以并行执行的，最后将结果commit到a的时候再串行就OK了；
如：a = b * 3; b = d + 5;， “读后写”依赖。同样，虽然第二条指令一定不能在第一条指令读取b的值之前就将b的值修改（确保第一条指令读到的是旧值），但是只要确保第一条指令先拿到b的旧值、或者直接跟生成b的旧值的那条指令关联上，之后两条指令还是可以并行执行的；
2、
CPU功能部件充足
CPU中用来执行具体操作的功能部件是有限的，假设CPU只有一个乘法器。
如：a = b * 3; c = d + 5; ，一个使用乘法器、另一个使用加法器，互不影响就可以并行；
如：a = b * 3; c = d * 5; ，两条指令都需要使用这个仅有的乘法器，就只能串行了（当然也未必是第一条指令先占用乘法器，因为可能它所依赖的b的值尚未ready、而第二条指令所需要的d已经OK）；
3、
CPU已经看到这两条指令
程序执行的指令序列可能无穷无尽（考虑到有循环），CPU为了挖掘并行性不可能一下子分析所有指令，一定会有个限度。在经典的流水线算法－－tomasulo算法－－中，这个限度就是RS（reservation station，保留站）的数目。CPU取指部件按指令顺序将指令放入RS，并设置它们的依赖关系（RS提供了这样的支持）。存在于RS中的指令当输入已经ready、且需要的功能部件有空余时，便会开始执行。
遇到分支指令时指令序列如何确定呢？分支指令在执行完成之前根本就不知道程序要往哪里走。解决办法就是分支预测，根据一些统计信息猜测程序的走向。然后无视这些分支，就跟没有分支时一样去执行。如果分支预测错了，再回滚回来，按正确的序列重新执行。
回到我们的例子，每个loop有一个load过程＋一个calc过程，calc过程依赖于load过程。但是下一次loop的load并不依赖于上一loop的calc过程，并且load和calc使用不同的CPU功能部件，所以这两个过程是可以并行的。（for循环在经历很多次loop之后才会退出，每次分支的走向都是一样的，可以近似认为分支预测一定成功。）
prefetch加与不加，前两个并行条件都是不会变的：prefetch既不会改变指令之间的依赖关系、也不会多占用或少占用CPU功能部件。但是为什么加上prefetch会有效果呢？
区别只在于第三个并行条件。试想当程序执行到第N次loop时（loop-N），由于calc过程复杂，指令很多，RS一直被占满。直到计算进入尾声，loop-(N+1)的指令才进入RS，这时CPU才知道要去load loop-(N+1)的input。而这些input在cache中不能命中，需要经历漫长的读内存过程，导致loop-(N+1)的calc指令卡在RS中得不到执行。相当于load和calc过程被串行化了。
加了prefetch之后呢？loop-(N+X)的prefetch指令排在loop-N的计算指令之前，早早的就能进入RS。这些load指令是计算的源头，其本身并没有依赖别的数据，所以一旦内存通道空闲下来prefetch就可以开始工作了。于是load与calc才正真并行起来。
如下面示意：
case-2，顺序读内存，cache全命中：
calc-11
calc-12
calc-13 calc-21
calc-22
calc-23 calc-31
calc-32
calc-33 calc-41
calc-42
calc-43 calc-51
calc-52
calc-53
（每个loop约花费2个单位时间。）
case-3，跳读内存，cache全不命中：
load-11
load-12
calc-11
calc-12
calc-13 load-21
load-22
calc-21
calc-22
calc-23 load-31
load-32
calc-31
calc-32
calc-33
（每个loop约花费4个单位时间。注，假设CPU执行到calc-N3的时候才看到有load-(N+1)1。）
case-4，跳读内存，加预取：
load-11
load-12
calc-11 prefetch-21
calc-12 prefetch-22
calc-13 calc-21 prefetch-31
calc-22 prefetch-32
calc-23 calc-31 prefetch-41
calc-32 prefetch-42
calc-33 calc-41 prefetch-51
calc-42 prefetch-52
calc-43 calc-51
calc-52
calc-53
（每个loop约花费2个单位时间。注，在calc-N1之前prefetch-(N+X)1就已经发起了。）
通过prefetch，使这些既耗时又被后续指令依赖的load指令提前进入CPU的视野，让CPU可以利用可能空闲的内存带宽，提前完成读操作。另一方面，使用prefetch预取内存之后，跟依赖于它的那些计算指令拉开了距离，使得计算指令不必等到马上就得使用load的输入时才临时抱佛脚。拉开相关依赖指令的距离正是编译器优化代码的一种常用手段，通常通过指令重排调整无关指令的顺序来实现。
到这里prefetch的大致逻辑已经理清楚了，但是仔细想一下其实问题还很多……
例子引出的问题
第一个问题，为什么case-3（读内存＋普通计算）的执行时间（66.041256）要比case-1（单纯的读内存）时间（23.980005）＋case-2（单纯的计算）时间（22.846302）更长呢？按理说，就算load指令和calc指令完全串行，case-3的执行时间最多也就等于1、2之合吧。
这个问题应该可以用内存多通道来解释。现在CPU访问内存的通道一般会有两个或以上。在case-1中，单纯的读内存其实并不代表串行的读内存。多个内存通道是可以让多个load指令并行工作的，以充分利用内存带宽。而在case-3中，由于引入了一堆计算指令，导致RS被装满，CPU无法同时看到当前loop和下一个loop的load请求，也就无法将两次load并行化。所以，更准确来说，case-3耗时这么长的原因并不是load与calc无法并行，而是load与load无法并行。loop-N的calc过程跟loop-(N+1)的load过程是并行的，但是在loop-(N+1) load完成并进行calc之前，loop-(N+2)的load指令还未进入CPU的视野，所以无法与loop-(N+1)的load并行。
如何证实这一点呢？
我们在case-1中加一个lfence指令试试看。lfence是x86提供的内存屏障指令，作用是确保load操作的顺序：lfence之前的load操作必须先于lfence之后的load操作。如此便打破了load的并行性（如果真如刚才所说，并行性存在的话）。
修改run函数如下：
int run(const int *array, int size, int step)
{
int result = 0;
printf("run...\n");
for (int i = 0; i < step; i++) {
for (int j = i; j < size; j += step) {
asm volatile("lfence");
result += calcu(array[j]);
}
}
return result;
}
再次运行case-1：
[case-1.1]$ g++ -O2 prefetch.cpp -DEMPTYCALC [case-1.1]$ ./a.out test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 63.999864, result: 692002678
（强制让load不能并行之后，case-1.1的耗时直接变成了case-3的水平。说明在原本的case-1中load是存在很大的并行度的。）
再以加lfence的代码运行一下case-6（未加prefetch、复杂计算）看看，如果在复杂计算＋跳读内存的情况下，读内存的并行性已经很少的话，加了lfence之后的耗时应该跟加之前差不多：
[case-6.1]$ g++ -O2 prefetch.cpp -DHEAVYCALC [case-6.1]$ ./a.out test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 114.787379, result: 1625037789
（果然如此。）
还可以同时运行两个程序来看看是什么情况。两个程序同时运行时，由于kernel load balance的作用，它们会尽量运行在不同的CPU上、且尽量不共享cache。那么，如果两个进程都总是能cache hit，则运行时间应该跟单个进程运行时差不多；反之如果总是cache miss，则两个进程会争抢内存带宽，运行时间会有所增加。
[case-2.2]$ ./prefetch.normal test.tar.gz 1 0 | ./prefetch.normal test.tar.gz 1 0 array size: 468787200, step: 1. run... time cost: 22.964594, result: 1309150882
（两个顺序读内存的普通计算一起运行，因为总是cache hit，所以跟单个运行的时间差不多。）
[case-1.2]$ ./a.out test.tar.gz 1024 0 | ./a.out test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 63.973557, result: 692002678
（两个加了lfence的进程一起运行，由于进程内的内存访问已经串行化了，两个进程可以各自使用一个内存通道，所以运行时间跟单个进程运行时差不多。）
[case-1.3]$ ./prefetch.empty test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 24.083044, result: 692002678 [case-1.4]$ ./prefetch.empty test.tar.gz 1024 0 | ./prefetch.empty test.tar.gz 1024 0 array size: 468787200, step: 1024. run... time cost: 37.948864, result: 692002678
（而用之前没加过lfence的程序再试一下，两个进程同时运行时，由于争抢内存带宽，运行时间就会受影响。）
prefetch提前量
还有一个问题也可以用内存多通道来解释，即prefetch提前量问题。先就之前的程序继续看几个case：
$ for x in 1 2 4 8 16 32; do ./prefetch.normal test.tar.gz 1024 $x; done array size: 468787200, step: 1024. run with prefetch(1)... time cost: 36.262511, result: 1309150882 array size: 468787200, step: 1024. run with prefetch(2)... time cost: 29.902517, result: 1309150882 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 28.052798, result: 1309150882 array size: 468787200, step: 1024. run with prefetch(8)... time cost: 26.040215, result: 1309150882 array size: 468787200, step: 1024. run with prefetch(16)... time cost: 26.198825, result: 1309150882 array size: 468787200, step: 1024. run with prefetch(32)... time cost: 25.910506, result: 1309150882
prefetch提前量从1增大到32。从结果看，当提前量小的时候，prefetch效果不明显。为什么呢？
假设提前量为1，那么loop-N会为loop-(N+1)进行预取。但是从前面普通计算的数据可以看出，就一个loop而言，load的时间是多于calc时间的（从总量上说，load并行之后才与calc时间相当，那么单独的load就应该比calc耗时长）。所以当执行到loop-(N+1)的时候，prefetch应该尚未完成。
再假设提前量为4，loop-N会为loop-(N+4)做预取，loop-(N+1)为loop-(N+5)预取。而在进入loop-(N+1)时，loop-(N+4)的预取尚未完成，而此时发起的loop-(N+5)的预取就能与之并行。可见增大提前量能更好的利用内存带宽。（虽然说以N为提前量就可以充分利用N个内存通道，但是机器上还有kernel和其他进程也在使用内存，未必就能让你独占内存带宽。所以使用大于N的提前量更能充分利用空余的内存带宽。）
当然提前量肯定不能太大，否则等真正用到数据的时候，预取好的数据可能已经被从cache中挤出去了。
用mov代替prefetch？
prefetch指令可以用来预取，难道不用prefetch就不行了么？
我们将之前的run_withprefetch函数
修改一下，把prefetch替换成简单的load操作：
int run_withprefetch(const int *array, int size, int step, int prefetch)
{
int result = 0;
printf("run with prefetch(%d)...\n", prefetch);
for (int i = 0; i < step; i++) {
for (int j = i; j < size; j += step) {
int k = j + step * prefetch;
if (k < size) {
const int *addr = &array[k];
asm volatile("mov (%0), %%eax"::"r"(addr):"eax");
}
result += calcu(array[j]);
}
}
return result;
}
重跑case-4：
[case-4.1]$ g++ -O2 prefetch.cpp [case-4.1]$ ./a.out test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 37.312423, result: 1309150882
确实比不加prefetch的情况case-3（66.041256）要好很多，但还是比不上原来的case-4（28.247350）。
那么prefetch比直接movload好在哪里呢？
1、使用mov也同样能达到让load操作提前进入CPU视野的目的
2、使用mov访问过的内存同样会被cache住
3、仅仅是因为mov操作多占用了一个寄存器么？把代码改成这样看看（使用原来的prefetch但是多占用一个寄存器）：
if (k < size) {
_mm_prefetch(&array[k], _MM_HINT_T0);
__asm__ __volatile__ ("mov %0, %%eax"::"r"(k):"eax");
}
[case-4.2]$ g++ -O2 prefetch.cpp [case-4.2]$ ./a.out test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 28.051848, result: 1309150882
可见仅仅多占用一个寄存器，貌似并没有什么影响。（在tomasulo算法中，这里实际上并没有多占用寄存器，而是多占用了RS。）
前面提到了tomasulo算法，提到了RS，这里面还有个东西叫ROB（reorder buffer，指令重排缓存）。前面还提到过对于“写后写”依赖指令，在执行过程中是可以并行的，只要保证最后写回的顺序不变就行了。ROB就能完成这个功能。
CPU取指令之后除了将其放入RS（让其可以乱序执行），还要按顺序将其放入ROB。执行完成后的指令最终在ROB中排队，然后按顺序提交（将结果写回寄存器或内存）。ROB还有另一个很重要的作用，就是分支预测失败时的回滚。分支指令也跟其他指令一样要在ROB中排队。如果分支指令执行完以后发现分支预测错了，则将ROB里排在这条分支之后的指令及其结果都清理掉就行了。因为ROB是按指令顺序排队的，由于分支预测出错而被错误执行的那些指令一定都排在分支指令之后。
回到我们的例子，”mov (addr), %eax”这条指令会一直占着ROB，直到load完成。这将导致后续的指令结果一直得不到提交，尚未被CPU取走的指令又会因为无法获得ROB而不能被取走。这又回到了类似于case-3（未加prefetch）的情形，指令无法大量进入CPU的视野，以致于内存访问无法占满内存带宽。只不过因为ROB的资源没有RS那么紧张，所以阻塞的情况没有case-3那么严重。
基于以上说明，我们改造case-6（未加prefetch、复杂计算）看看。对于复杂计算，calc过程的指令更多，按理说，阻塞的情况会更严重，直接load应该效果更差。
[case-6.2]$ g++ -O2 prefetch.cpp -DHEAVYCALC [case-6.2]$ ./a.out test.tar.gz 1024 4 array size: 468787200, step: 1024. run with prefetch(4)... time cost: 100.910547, result: 1625037789
果然，这个结果比起原本的case-6（107.783801）已经没有优势了。
那么为什么prefetch不会受ROB的大小限制呢？因为prefetch是一个特殊指令，没有输出，对程序上下文也没有影响，甚至于分支预测失败时也不需要回滚。那么CPU完全没必要让prefetch指令进ROB（当然RS还是要进的，因为prefetch可能依赖于前面指令的结果）。
其他问题
关于硬件prefetch
虽然CPU提供了显式prefetch指令，其实它自己暗中也会进行一些prefetch，可以称之为硬件prefetch。
硬件prefetch有这么几个要点：
1、CPU在经历连续一定次数的cache miss后触发。偶尔发生的一次cache miss是很正常的，比如访问一个不常使用的全局变量；
2、CPU有一定的模式匹配策略，能够识别顺序访问和一些固定step的跳跃访问；
3、最重要的一点，硬件prefetch不会跨page进行。因为内存是按page管理的，跨page意味着可能触发page fault，这是CPU自己所无法handle的，得由kernel来解决。CPU暗中的prefetch动作对软件来说本来是透明的，不能让kernel去handle可能本不应发生的page fault，甚至于这样的page fault可能导致segment fault（相反，软件prefetch是软件自己发起的，有什么后果自己承担）；
基于第3点，CPU一般不会试图去识别步长高于512字节的跳跃访问。因为要经历三次cache miss，CPU才能发现跳读内存的步长是相同的（pos2 – pos1 == pos3 – pos2），而后如果触发硬件prefetch的话，大于512字节的步长可能使得访存操作很快跨跃page边界，触发prefetch意义已经不大了。
我们可以继续用前面的程序来观察一下硬件prefetch的表现。将step从1到1024递增，不使用软件prefetch：
$ for x in 1 2 4 8 16 32 64 128 256 512 1024; do ./prefetch.normal test.tar.gz $x 0; done array size: 468787200, step: 1. run... time cost: 22.863716, result: 1309150882 array size: 468787200, step: 2. run... time cost: 23.438035, result: 1309150882 array size: 468787200, step: 4. run... time cost: 23.846166, result: 1309150882 array size: 468787200, step: 8. run... time cost: 24.171723, result: 1309150882 array size: 468787200, step: 16. run... time cost: 25.502980, result: 1309150882 array size: 468787200, step: 32. run... time cost: 37.461018, result: 1309150882 array size: 468787200, step: 64. run... time cost: 39.829086, result: 1309150882 array size: 468787200, step: 128. run... time cost: 44.291904, result: 1309150882 array size: 468787200, step: 256. run... time cost: 65.332225, result: 1309150882 array size: 468787200, step: 512. run... time cost: 64.764071, result: 1309150882 array size: 468787200, step: 1024. run... time cost: 65.952260, result: 1309150882
随着step的逐步增大，可以看出时间消耗分为三个档次：
step 1~16，cost 22~25，因为16个int是64byte，正好在一个cache line中。这么小的step再加上硬件预取基本上都能cache hit了；
step 32~128，cost 37~44，这个区间的cost跨度较大。在这些step下，单个page内读取值的个数分是32、16、8，硬件prefetch尚有一定的余地被触发、并发挥作用。然后随着可预取数目的减少，cost也不段增加；
step 256~，cost 64~65，步长超过了1024byte，硬件prefetch已经不会被触发；
关于TLB cache miss
应用程序中使用地址的都是虚拟地址，访问内存时存在虚拟地址到物理地址的转换过程。转换规则（即页表）是放在内存中的，并由TLB来cache。地址转换需要跳多级页表、多次读内存，所以如果TLB cache miss，代价是很大的。
不过在我的环境中貌似并不存在TLB cache miss的问题。继续改造程序验证一下：
int run(const int *array, int size, int step, int blocksize)
{
int result = 0;
blocksize *= 4096;
if (blocksize == 0) {
blocksize = size;
}
printf("run... (block=%d pages)\n", blocksize/4096);
int start = 0;
int nsize = blocksize;
while (nsize == blocksize) {
if (start + blocksize > size)
nsize = size - start;
for (int i = 0; i < step; i+=32) {
for (int j = i; j < nsize; j += step) {
int thissize = j + 32 < nsize ? j + 32 : nsize;
for (int k = j; k < thissize; k++) {
result += calcu(array[start+k]);
}
}
}
start += nsize;
}
return result;
}
改造run函数把整个文件按blocksize划分成若干个块，每个块单独完成跳读逻辑。
于是，当块比较小时块内跳读时所涉及的page比较少，TLB应该能将相关的页表都cache住；而当块比较大，可能就会出现TLB cache miss。
这里面还存在另一个问题，按之前的做法，每个int跳一次。如果块比较小，第一轮跳读时可能整个块都被cache了，后续的跳读都将cache hit。而块大时又无法cache整个块，后续的跳读又将继续cache miss。这就对观察TLB cache miss产生很大影响。所以程序改成每32个int跳读一次（按前面的结果，跳读32以后性能就不好了），以忽略cache hit所带来的影响。
修改main函数，用第4个参数来传递blocksize（0值表示不分block）：
$ for x in 128 256 512 1024 0; do ./a.out test.tar.gz 1024 $x; done array size: 468787200, step: 1024. run... (block=128 pages) time cost: 22.501363, result: 1309150882 array size: 468787200, step: 1024. run... (block=256 pages) time cost: 22.627935, result: 1309150882 array size: 468787200, step: 1024. run... (block=512 pages) time cost: 25.064514, result: 1309150882 array size: 468787200, step: 1024. run... (block=1024 pages) time cost: 24.976720, result: 1309150882 array size: 468787200, step: 1024. run... (block=114450 pages) time cost: 24.900870, result: 1309150882
看起来TLB cache miss所带来的影响不大。
关于L1 cache
前面一直在讲cache，并没有细分是第几级的cache。其实前面的例子对内存的使用并没有那么精细，主要利用的cache还是L2 cache。
继续用前面分块的例子来看看，因为要考查cache，所以把连读32个int的逻辑去掉。run函数改造如下：
int run(const int *array, int size, int step, int blocksize)
{
int result = 0;
blocksize *= 4096;
if (blocksize == 0) {
blocksize = size;
}
printf("run... (block=%d pages)\n", blocksize/4096);
int start = 0;
int nsize = blocksize;
while (nsize == blocksize) {
if (start + blocksize > size)
nsize = size - start;
for (int i = 0; i < step; i++) {
for (int j = i; j < nsize; j += step) {
result += calcu(array[start+j]);
}
}
start += nsize;
}
return result;
}
在一个块内反复跳读，如果以块的大小刚好能被cache住，则程序运行时间会很短；否则又得经历漫长的读内存过程。
$ for x in 1 2 4 8 16 32 64 128 256 512 1024; do ./a.out test.tar.gz 1024 $x; done array size: 468787200, step: 1024. run... (block=1 pages) time cost: 1.614654, result: 692002678 array size: 468787200, step: 1024. run... (block=2 pages) time cost: 1.554286, result: 692002678 array size: 468787200, step: 1024. run... (block=4 pages) time cost: 1.625566, result: 692002678 array size: 468787200, step: 1024. run... (block=8 pages) time cost: 2.621453, result: 692002678 array size: 468787200, step: 1024. run... (block=16 pages) time cost: 2.697908, result: 692002678 array size: 468787200, step: 1024. run... (block=32 pages) time cost: 2.724401, result: 692002678 array size: 468787200, step: 1024. run... (block=64 pages) time cost: 2.710056, result: 692002678 array size: 468787200, step: 1024. run... (block=128 pages) time cost: 3.864916, result: 692002678 array size: 468787200, step: 1024. run... (block=256 pages) time cost: 4.241000, result: 692002678 array size: 468787200, step: 1024. run... (block=512 pages) time cost: 20.216653, result: 692002678 array size: 468787200, step: 1024. run... (block=1024 pages) time cost: 24.361176, result: 692002678
随着block size的逐渐增大，程序运行时间显现出三个层次。分别代表着L1 cache hit（1〜4）、L2 cache hit（8〜256）、cache miss（512〜）三种状态。看起来L1 cache在本例中影响并不大。