Cache為什麼有那麼多級?為什麼一級比一級大?是不是Cache越大越好?

來源:互聯網
上載者:User
這是一個建立於 的文章,其中的資訊可能已經有所發展或是發生改變。點擊上方“公眾號” 可以訂閱哦!

通過我們前面的系列文章,大家對Cache的組織形式和特性都有了一定的瞭解。有個問題不知道大家思考過沒有:為什麼Cache分這麼多級,而是不是直接把L1或者L2增大了事?我們為什麼不能直接做出個Cache奇大的CPU呢?下面我們來一一分析。

為什麼Cache要分級?

前文(L1,L2,L3 Cache究竟在哪裡?)中我們提到CPU中有L1、L2、L3甚至L4級Cache。為什麼搞這麼麻煩,製程提高,可以放更多晶體管了,CPU廠商直接把L1和L2加倍不就好了嗎?

要回答這個問題,首先我們要知道L1和L2 Cache的區別,它們的構造一樣嗎?答案是否定的,雖然它們都是由CAM(Content Addressable Memory )為主體的tag和SRAM組成的,但是區別卻是明顯的:L1(先不考慮指令和資料L1的不同)是為了更快的速度訪問而最佳化過的,它用了更多/更複雜/更大的晶體管,從而更加昂貴和更加耗電;L2相對來說是為提供更大的容量最佳化的,用了更少/更簡單的晶體管,從而相對便宜和省電。同樣的道理還可以推廣到L2和L3上。

在同一代製程中,單位面積可以放入晶體管的數目是確定的,這些晶體管如果都給L1則容量太少,Cache命中率(Hit Rate)嚴重降低,功耗上升太快;如果都給L2,容量大了但延遲提高了一個數量級:

如何平衡L1、L2和L3,用固定的晶體管數目達成最好的綜合效果,這是一種平衡的藝術。在多年實踐之後,現在已經相對固定下來,Intel和AMD的L1 Cache命中率,現在往往高於95%,增加更多的L1效果不是很顯著,現在更多的是增大L3,以達到花同樣的代價,幹更多的事的目的。

Cache為什麼不會做的很大?

L3現在動輒數十M,比以往那是闊綽很多了,但相對摩爾定律增長的記憶體容量來說則大幅落後。為什麼Cache增長這麼緩慢?還是Cost的問題。一個最簡單的SRAM就要消耗6個晶體管:

再加上Tag,最少需要數十個晶體管,代價很大。我們花這麼大的代價增加Cache,衡量效能的命中率是如何變化的呢?

為簡化起見,我們假設L1維持在不到60%的命中率(實際情況95%左右)。可以看出,隨著L2容量的增加,開始時L2和整體命中率快速提高,這表明提高L2容量效用很明顯。隨後L2的命中率在容量增加到64KB後增長趨緩,而整體命中率也同時趨緩,最後甚至基本不大變化了。增加同樣的晶體管,而受益卻越來越少,出現了邊際效用遞減的問題。

我們上文(Cache是怎麼組織和工作的?)中不同的映射關係會不會使結果不同呢?

圖片來源 ExtremTech

從這個圖中我們看出不同的映射關係,從直接映射(1 way-Associative)到16路,儘管明顯16路更好,但是還是在size達到64KB左右,增加cache size用處不大了。

如此說來,製程進化得來的多餘晶體管,在做Cache效益不明顯的前提下,還不如把它們拿來做個Core什麼的,或者再多做一級Cache!這也是為什麼Cache不再增加,而級數增加的原因了。目前我知道Cache size佔據Die面積最大的就數這款Pentium M的Die了:

注意左邊都被L2 Cache佔據,右邊還有些L1 Cache,整體大於65%的Die size被用於Cache。

一個腦洞

我們暫時放下討厭的Cost和製程問題,假設我們有錢任性,做出一個A4紙一樣大的L1 cache,把我們尊貴的Core放在正中間,像這樣:

我們的L1 Cache可以做到1G,完全不要記憶體,我們會不會得到一個效能超贊的CPU呢?不幸的是,並不會。因為L1做的這麼大,要在一個時鐘域內(同步時鐘設計遠比非同步簡單)可以訪問所有單元,時鐘頻率做不到很高,而Core因為要在一個周期內操作L1,也不得不放棄3G以上的身價,而大大降低頻率。綜合下來也許還不如一部分做L1,一部分做L2和L3。這樣L1就可以頻率很高,Core也不需要自貶身價了。這也從另一方面證明了Cache分級的必要性。

結論

Intel大約每過10年,就會增加一級新的Cache。到現在已經有了L4的Cache。另一方面同樣多的晶體管,到底是用來做Cache還是做更好的分支預測器,亦或更多的core,這也在考驗設計師的能力。

下一篇將介紹CAM(Content Addressable Memory )為主體的tag以及它和SRAM的關係,敬請期待。


相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.