本站消息

站长简介/公众号

  出租广告位,需要合作请联系站长

+关注
已关注

分类  

暂无分类

标签  

暂无标签

日期归档  

2024-11(1)

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

发布于2021-03-14 05:45     阅读(1360)     评论(0)     点赞(25)     收藏(5)


在《内存随机也比顺序访问慢,带你深入理解内存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的关系。所以不要觉得内存很快,就用起来太随性了!


file


开发内功修炼之内存篇专辑:


我的公众号是「开发内功修炼」,在这里我不是单纯介绍技术理论,也不只介绍实践经验。而是把理论与实践结合起来,用实践加深对理论的理解、用理论提高你的技术实践能力。欢迎你来关注我的公众号,也请分享给你的好友~~~



所属网站分类: 技术文章 > 博客

作者:gogogo

链接:http://www.phpheidong.com/blog/article/3034/8d172a482cb35b464737/

来源:php黑洞网

任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任

25 0
收藏该文
已收藏

评论内容:(最多支持255个字符)