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

1、先測順序IO情況

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

在這個核心代碼的基礎上，我們有兩個可調(diào)節(jié)變量：

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

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

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

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

場景一：固定數(shù)組大小2K，調(diào)節(jié)步長

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

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

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

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

和場景二相比，步長變大以后，局部性變差，穿透的內(nèi)存IO進一步增加。雖然數(shù)據(jù)量一樣大，但是平均耗時就會繼續(xù)有所上漲。不過雖然穿透增加，但由于訪問地址仍然相對比較連續(xù)，所以即使發(fā)生內(nèi)存IO也絕大部分都是行地址不變的順序IO情況。所以耗時在9ns左右，和之前估算大致相符！

另外注意一個細節(jié)，就是隨著數(shù)組從64M到32M變化的過程中。耗時有幾個明顯的下降點，分別是8M，256K和32K。這是因為本機的CPU的L1大小是32K，L2是256K，L3是12M。在數(shù)據(jù)集32K的時候，L1全能裝的下，所有基本都是高速緩存IO。256K的時候、8M的時候，雖然L1命中率下降，但是L2、L3訪問速度仍然比真正的內(nèi)存IO快。但是超過12M以后越多，真正的內(nèi)存IO就越來越多了。

2、再測隨機IO情況

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

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

隨機實驗場景：數(shù)組從32K到64M

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

3、結論

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



審核編輯：劉清