实际测试内存在顺序IO和随机IO时的访问延时差异

在《内存随机也比顺序访问慢，带你深入理解内存IO过程》一文中，我们理解了内存IO的内部实现过程，知道了内存的随机IO比顺序IO要慢，并对延迟时间进行了大概的估算。那么我们今天来用代码的方式来时间一下，看看在我们的项目工程中，内存访问的在不同的访问场景下延时究竟是个什么表现。

先测顺序情况

测试原理就是定义一个指定大小的double（8字节）数组，然后以指定的步长去循环。这里面的变量有两个。核心代码如下：

void init_data(double *data, int n){  
    int i;  
    for (i = 0; i < n; i++)	{  
		data[i] = i;    
	}  
}  
 
void seque_access(int elems, int stride) {    
    int i;  
    double result = 0.0;   
    volatile double sink;   
 
    for (i = 0; i < elems; i += stride) {  
		result += data[i];    
    }  
    sink = result;  
}

在这个核心代码的基础上，我们有两个可调节变量：

• 一是数组大小，数组越小，高速缓存命中率越高，平均延时就会越低。
• 二是循环步长，步长越小，顺序性越好，同样也会增加缓存命中率，平均延时也低。
  我们再测试的过程中采取的办法是，固定其中一个变量，然后动态调节另外一个变量来查看效果。

>另外说明一下，这个代码测试中考虑的几个额外的开销的处理情况。
1.加法开销：由于加法指令简单，一个CPU周期就可完成，CPU周期比内存周期要快，所以暂且忽略它。
2.耗时统计：这涉及到高开销的系统调用，本实验通过跑1000次取一次耗时的方式来降低影响。

场景一： 固定数组大小2K，调节步长

步长	1	9	17	25	33	41	49	57
延时ns	1.28	1.28	1.33	1.30	1.30	1.41	1.45	1.4

数组足够小的时候，L1 cache全部都能装的下。内存IO发生较少，大部分都是高效的缓存IO，所以我这里看到的内存延时只有1ns左右，这其实只是虚拟地址转换+L1访问的延时。

场景二： 固定步长为8，数组从32K到64M

数组大小	32K	64K	256K	512K	2M	8M	16M	64M
延时ns	1.27	1.73	2.03	2.62	2.62	2.88	5.17	5.84

当数组越来越大，Cache装不下，导致穿透高速缓存，到内存实际IO的次数就会变多，平均耗时就增加

场景三： 步长为32，数组从32K到64M

数组大小	32K	64K	256K	512K	2M	8M	16M	64M
延时ns	1.25	1.74	2.03	2.47	2.47	3.29	7.73	8.89

和场景二相比，步长变大以后，局部性变差，穿透的内存IO进一步增加。虽然数据量一样大，但是平均耗时就会继续有所上涨。不过虽然穿透增加，但由于访问地址仍然相对比较连续，所以即使发生内存IO也绝大部分都是行地址不变的顺序IO情况。所以耗时在9ns左右，和之前估算大致相符！
　
> 另外注意一个细节，就是随着数组从64M到32M变化的过程中。耗时有几个明显的下降点，分别是8M，256K和32K。这是因为本机的CPU的L1大小是32K，L2是256K，L3是12M。在数据集32K的时候，L1全能装的下，所有基本都是高速缓存IO。256K的时候、8M的时候，虽然L1命中率下降，但是L2、L3访问速度仍然比真正的内存IO快。但是超过12M以后越多，真正的内存IO就越来越多了。

再测随机IO情况

在顺序的实验场景里，数组的下标访问都是比较有规律地递增。在随机IO的测试中，我们要彻底打乱这个规律，提前随机好一个下标数组，实验时不停地访问数组的各个随机位置。

void init_data(double *data, int n){  
    int i;  
    for (i = 0; i < n; i++)	{  
		data[i] = i;    
	}  
}  
 
void random_access(int* random_index_arr, int count) { 
	int i;
    double result = 0.0; 
    volatile double sink; 
 
    for (i = 0; i < count; i++) {
		result += data[*(random_index_arr+i)];  
    }
    sink = result; 
}

>这实际比上面的实验多了一次内存IO，但由于对random_index_arr的访问时顺序的，而且该数组也比较小。我们假设它全部能命中高速缓存，所以暂且忽略它的影响。

随机实验场景： 数组从32K到64M

数组大小	32K	64K	256K	512K	2M	8M	16M	64M
延时ns	2.4	2.4	2.4	4.8	4.8	19.2	24	38.4

这次的数组访问就没有步长的概念了，全部打乱，随机访问。当数据集比较小的时候、L1、L2、L3还能抗一抗。但当增加到16M、64M以后，穿透到内存的IO情况会变多，穿透过去以后极大可能行地址也会变。在64M的数据集中，内存的延时竟然下降到了38.4ns，和我们估算的也基本一致。

结论

有了实验数据的佐证，进一步证实了上一文《深入理解内存IO的实际过程！》的结论。内存也存在随机访问比顺序访问慢的多的情况，大概是4:1的关系。所以不要觉得内存很快，就用起来太随性了!

---

在这里我不是单纯介绍技术理论，也不只介绍实践经验。而是把理论与实践结合起来，用实践加深对理论的理解、用理论提高你的技术实践能力。