深入理解计算机系统实验日志（二）——memory mountain
简介：
存储器山：具有不同的时间局部性和空间局部性的程序，对存储器层次结构的利用效率是不同的。局部性较好，则能得到较快的访问速率。构造一个存储器测试程序，以不同的时间局部性和空间局部性对存储器进行访问，就能得到存储器系统在不同的局部性下的性能（即访问速率）。以控制时间局部性的变量为x轴，控制空间局部性的变量为y轴，存储器访问速率为z轴，就能得到一个三维图形，它看起来像一座有着山峰，山脊和山坡的小山，即存储器山。（参考百度百科）
*本文将简单介绍如何自制存储器山并对实验结果进行详细分析。
I. 制作过程
（在课本主页下载存储器山的源代码并运行）
代码下载地址：csapp主页——“Chapter 6: The Memory Hierarchy”——“A less sophisticated program from the CS:APP2e text for generating the memory mountain (tar)”——点击tar即可下载
代码运行：mountain.c这个文件中包含对另外两个自定义的头文件（“clock.h”以及“fcyc2.h）的引用，运行前都需要自动编译：make
生成可执行文件：./mountain>output_ucloud.txt
注意：本地编译完成的文件不能直接在ucloud上运行，会报错“cannot execute binary file: Exec format error”，因此需要重新编译再运行
II. 实验结果分析：
首先总体观察读吞吐量，在各个情况下，都较Core i7山较高，而本机的处理器为 Intel Core i5，处理器速度为 1.6 GHz，对比处理器Core i7的2.1GHz主频较低。但是查找资料了解到，主频值越大，虽然一个时钟周期里面完成的指令数也越多，但是CPU的运行速度不一定越强，它还与处理器内部结构等很多因素相关。
（1）本地存储器山
-
保持步长为常数4，取出一个片段来观察高速缓存大小和时间局部性对性能的影响，本地配置L1缓存没有直接显示，但是根据实验结果可知，大小最大为32KB情况的吞吐量为20MB/s左右，上升到64KB时明显下降，由此可知32KB的工作集完全能放进L1缓存中，即其容量。对照缓存容量配置，理论上，大小最大为256KB的工作集完全能放进统一的L2高速缓存中，最大为4MB的工作集完全能放进统一的L3高速缓存中，具体分析后面会继续展开。
-
本地存储器山与Core i7山的最大区别是：
Core i7山是在高速缓存区域最左边的边缘上读吞吐量才出现下降，并且保持步长不变时，读吞吐量随着数据规模的上升保持下降的趋势。
而本地存储器山出现很多条沟壑，步长为1时，数据规模为64k、256k、1024k的读吞吐量出现了明显的下陷，导致很多山峰的出现，64k出现下降很容易想明白是由于用到了L2高速缓存；在步长为2、3时，256k～2m的读吞吐量基本保持不变，说明在实际运行情况下，256k的工作集并不能刚好放进统一的L2高速缓存中；而1024k的下降并不完全清楚原因，也只有出现在步长为1时，可能由于程序运行过程中的某些特殊原因造成。 -
同样，保持工作集大小为常数16k或32k，观察空间局部性对性能的影响，随着步长的上升，读吞吐量并非随之下降，出现了小幅度的起伏（云主机山也有类似情况出现），但是读吞吐量都保持在20MB/s以上，说明这时候的空间局部性对性能的影响较小，而分析原因可能是其他进程也在运行，用到了L1高速缓存，而此时工作集又完全在L1高速缓存中，所以容易受到影响，出现波动（云主机上有其他用户在某个时间点共享处理器）。除此之外，其他工作集由于需要用到除L1之外的存储器层，读吞吐量都保持了平稳的下降。
（2）云主机山
-
保持步长为常数，当数据规模从1024k上升到2m的时候，读吞吐量（时间局部性）骤降，虽然由于主机配置是保密的，被拒绝查看，不能得到确切云主机的存储配置，我们可以容易猜测出是由于需要访问主存所致，而且可以得出主存和高速缓存层的访问速度差距较大，即使空间局部性较好也无法补救。而高速缓存各层的访问速度差异不明显。所以在云主机上，根据实验结果，时间局部性比空间局部性更重要。
此外，依据时间局部性山脊，我们观察出大小最大为64KB的工作集完全能放进统一的L1高速缓存中，最大为256KB的工作集完全能放进统一的L2高速缓存中。 -
保持工作集大小不变，和Core i7山类似的是，它有平坦的山脊线，例如，对于步长1垂直于步长轴，读吞吐量为28GB/s，说明云主机的系统中也采用硬件预取机制，试图在一些块被访问之前，将它们取到高速缓存中；与Core i7山又有所区别的是，它出现了很多条这样的山脊线，说明云主机系统中的该机制对多个步长都适用。