在《內存隨機訪問也比順序慢，帶你深入理解內存IO過程》一文中，我們理解了內存IO的內部實現過程，知道了內存的隨機IO比順序IO要慢，并對延遲時間進行了大概的估算。那么我們今天來用代碼的方式來實踐一下，看看在我們的項目工程中，內存訪問的在不同的訪問場景下延時究竟是個什么表現。

1、先測順序IO情況

測試原理就是定義一個指定大小的double（8字節）數組，然后以指定的步長去循環。這里面的變量有兩個。核心代碼如下：

在這個核心代碼的基礎上，我們有兩個可調節變量：

一是數組大小，數組越小，高速緩存命中率越高，平均延時就會越低。

二是循環步長，步長越小，順序性越好，同樣也會增加緩存命中率，平均延時也低。我們在測試的過程中采取的辦法是，固定其中一個變量，然后動態調節另外一個變量來查看效果。

另外說明一下，這個代碼測試中考慮的幾個額外的開銷的處理情況。

1.加法開銷：由于加法指令簡單，一個CPU周期就可完成，CPU周期比內存周期要快，所以暫且忽略它。
2.耗時統計：這涉及到高開銷的系統調用，本實驗通過跑1000次取一次耗時的方式來降低影響。

場景一：固定數組大小2K，調節步長

數組足夠小的時候，L1 cache全部都能裝的下。內存IO發生較少，大部分都是高效的緩存IO，所以我這里看到的內存延時只有1ns左右，這其實只是虛擬地址轉換+L1訪問的延時。

場景二：固定步長為8，數組從32K到64M

當數組越來越大，Cache裝不下，導致穿透高速緩存，到內存實際IO的次數就會變多，平均耗時就增加

場景三：步長為32，數組從32K到64M

和場景二相比，步長變大以后，局部性變差，穿透的內存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就越來越多了。

2、再測隨機IO情況

在順序的實驗場景里，數組的下標訪問都是比較有規律地遞增。在隨機IO的測試中，我們要徹底打亂這個規律，提前隨機好一個下標數組，實驗時不停地訪問數組的各個隨機位置。

這實際比上面的實驗多了一次內存IO，但由于對random_index_arr的訪問時順序的，而且該數組也比較小。我們假設它全部能命中高速緩存，所以暫且忽略它的影響。

隨機實驗場景：數組從32K到64M

這次的數組訪問就沒有步長的概念了，全部打亂，隨機訪問。當數據集比較小的時候、L1、L2、L3還能抗一抗。但當增加到16M、64M以后，穿透到內存的IO情況會變多，穿透過去以后極大可能行地址也會變。在64M的數據集中，內存的延時竟然下降到了38.4ns，和我們估算的也基本一致。

3、結論

有了實驗數據的佐證，進一步證實了《內存隨機訪問也比順序慢，帶你深入理解內存IO過程》的結論。內存存在隨機訪問比順序訪問慢的多的情況，大概是4:1的關系。所以不要覺得內存很快，就用起來太隨性了!



審核編輯：劉清