Re: [轉錄][閒聊]內存定址速度，好像大家都不關心?

講到軟體對記憶體系統的最佳化就是來釣我的.......... : ※ [本文轉錄自 C_and_CPP 看板 #1DX4728p ] : 作者: DrStein (啤酒肚) 看板: C_and_CPP : 標題: [閒聊]內存定址速度，好像大家都不關心? : 時間: Sat Mar 19 13:40:15 2011 不是不關心,而是內存(RAM)到緩存(cache)的速度, 啊...實際上就等於記憶體控制器如何去存取DRAM的速度. 對程式設計者來說黑箱的因素太大.最佳化比較單純的 RAM種類如SRAM,1T-SRAM,RAMBUS DRAM(不算太單純但比SDRAM好) 不是主記憶體的主流,而自JEDEC SDRAM以降的體系(包含到目前的DDR2/DDR3) 由於是持續演進的,它的存取規則與cycle的關係雖然可以預期在哪個範圍, 可是很難計算出怎麼樣的位址間隔對它是最佳化的存取順序. 再說就算固定變成成同一個記憶體控制器上好了(意思是,同一顆北橋晶片或者是 同一顆cpu...),記憶體組態不同,使用者插1GBx2雙通道,1GBx2但是單通道,2GBx2, 2GB+1GB,512MBx4等等.這些不同的實體組態會導致記憶體控制器的Bank Open/Close 的policy都不同,最佳化的存取順序也不同.組態只要變化就不同,根本就不能設計 只針對記憶體控制器的效能而非針對cache最佳化的code..... 介紹RAM的文件很多,不過介紹到記憶體控制器如何運作基本的文件我也只看過一篇 An introduction to SDRAM and memory controllers (Benny Akesson), 另外手邊若有Computer Architecture:A Quantitiative Approch第二版的,也有介紹 如何應用Bank Interleave去最佳化.三版四版的有沒有拿掉我不確定.... 不然若要詳細知道這問題,從基本功開始練起,可以參閱近期有本書:Memory Systems: Cache,DRAM and Disks看建立基本觀念後能不能想出一些做法. 基本上我是認為除非組態已經很確定了例如嵌入式系統,否則針對記憶體控制器的 最佳化實在是沒有投入的效益.....一般程式設計者能知道(假如有)scratchpad memory 如何應用,preload指令,改變資料排列的順序或者是大小以適應cache等的做法 (同樣CAAQA第二版也有詳細介紹...新版不太記得)就已經很夠用了. 另外文中提到硬體上的分級是有可能的,因為不同記憶體控制器的實做規則不同 的確會影響很大的效能,比如Sis當年搶先推出首款雙通道DDR-400的655Max, 不過它的記憶體存取效能還輸給Intel E7205裝雙通道DDR-266...不過目前 記憶體控制器都內建在cpu中了,所以能做分級變成cpu層級的問題而不是晶片組. -- ◆ From: 114.37.182.84 03/19 22:04 還是簡化這個問題好了,我們把記憶體容量直接展開成一個二維的東西. 1 2 3 ....... N+1 N+2 N+3 ....... 2N+1 2N+2 2N+3 ....... 請問我連續存取三筆資料,若是存取1,2,3這順序有甚麼好處?若是存取 1,N+1,2N+1有甚麼好處?當我接連做多次存取,應該採用1,2,3的順序或者是 1,N+1,2N+1 ? 還有,寫軟體的時候我怎麼知道N是多少?基本問題可以這幾個 做例子... OK,你的疑問就是你需要的答案,記憶體相關的benchmark不準, 主因是記憶體控制器的排程規則對軟體撰寫者而言就是很黑箱,無從 最佳化起才導致的結果.A軟體寫出來的和B軟體能得到的不同.或者是 由於其它變因不一樣,同樣程式不同環境下的Bank conflict的次數過高等等.. 還有可能是我講解的方式的問題,我完全不是拿單一測試來延伸推論, 而是從現成的資料(就算書單-CAAQA二版跟Memory System不看,也應該去看 文章有提的Benny Akesson的pdf,也沒有多少頁,看完才質疑不遲)來推 還有這件事情有點像,某個人想要改車,問的不是改引擎或者是改輪胎等, 而是問如何先把車殼打磨到最低的風阻讓它更快.... 而我的解答: 1.計算這東西太複雜了..而且最後的效益又很難證明比你先改引擎跟輪胎好 2.大概要設計高階賽車再來煩惱這問題,否則就很沒效益. 大概是這樣的回答方式... 嗯 如何壓榨出各種記憶體控制器讀寫的最大效率的應用... 有啦,有一個實際例子,Sissoft Sandra的記憶體測試就是有特別針對不同記憶體 控制器最佳化...不過這沒有實際太大的意義. 另外很少需要這方面的應用(除非你是嵌入式系統,PS3/360,或者已經最佳化 到極限)的原因也是很簡單,如果一個程式依賴壓榨記憶體系統最大的速度,表示 在這個程式上cache幾乎不產生效果.那麼不是有很特殊的原因...就是需要如preload 等技巧輔助. cpu上的cache為主,因為效率差太多了,假設說我的程式原本一秒要做一百萬次記憶體 存取,而其中70%是cache hit,使用3 cycle,而剩下30%是cache miss,使用20個cycle, 光改寫軟體假設提升cache hit達到90%,那麼就會加速很多,而這個過程就是對cache的最 佳化..... 舉例而言.... 1.對cache block size的最佳化 cache一次會讀入一個block大小.這個大小可能在8~64byte之間,而同一個block中的 其他資料就不用再重新讀入一次, 假設cache block是32 byte,程式有一個自訂的結構S,有{w,x,y,z,t} 5個int元素, 共有100000組資料使用結構S的陣列儲存,而且程式一開始就要讀入陣列中每個W值... 那麼,由於每讀取兩個W平均超過一個會cache miss,平均cache hit的比例會接近 (32-20)/32=12/32=3/8=37.5%, 但如果把W值另外儲存成一個連續的陣列.那麼平均cache hit的比例就是(32-4)/32= 28/32=87.5%.大約比前者快了兩倍多.... 2.對cache size的最佳化 常用在超大矩陣的運算尤其乘法.由於矩陣乘法要循序讀入矩陣的每個ROW,拿去乘完 另外一個矩陣的column.再來同樣全部讀入一次並乘上下一個column...依此類推. 假設矩陣比cpu cache的尺寸大,那麼當ROW X被第二次讀入的時候,cache內早就 被他後面的ROW塞滿,原有的ROW X被捨棄掉....因此又會cache miss而重新讀取一次. 這樣幾乎100%都是cache miss. 那麼只能把這個大型矩陣的乘法拆成小型的,讓每個子乘法程序所要讀取的資料 都小於cache size,那麼cache hit的比率就會很高 而不是幾乎等於0. 3.preload 假定知道程式的某個讀取記憶體動作一定會cache miss,而cache miss後 從記憶體內讀出的cycle時間又差不多已知,那麼就可以在這行的前面N個cycle 的地方先插入preload指令,而執行到原本要讀取的那一行的時候就剛好讀進cache. 可以以cache hit的效率讀取到. preload也可能別稱latency hidden,同樣技巧其實現實生活中也會出現一樣的例子. 假定我坐捷運從車頭上車,但是我確定等等下車要在台北車站的車尾部分的電扶梯 離開,所以我就在車子行駛中先由車頭走到車尾,省掉下車後才走的時間....這就是 標準的latency hidden的行為(走的距離並無縮短,但是時間減少了....) memory controller有變化,以往在北橋晶片組的時候會比較明顯. 不同家晶片組,同一家晶片組的高低階(如Intel i875有PAT,i865沒有...) 就會差很多. 但一來這東西太少資料,二來很少軟體可以看出差異.所以就被隱藏了. 因原文在c and cpp版面發表所以想法會比較偏向軟體面的介紹...
※ 批踢踢實業坊(ptt.cc)
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1300543133.A.420.html

推 Radeon:太深奧...理解不能!! 03/19 22:01

→ jk21234:我很懶 這篇只有關鍵字 沒有基礎觀念... 03/19 22:01

→ EndlessYearn:看不懂... 隔行如隔山... 03/19 22:03

推 Sousake:出現了！！ 推推 03/19 22:04

推 pomelo168168:看文這篇我大腦快當機了...先去睡覺(￣ー￣；) 03/19 22:04

→ suzukihiro:我只看得懂最後的實際例子 03/19 22:05

推 montyui:專業推 但我看不懂XD 03/19 22:17

推 smkingpk:快推 不然別人會以為我們看不懂(迷 ： 實際上就看不懂..) 03/19 22:18

→ jk21234:這問題我不懂 但之前研究的結果是不用弄懂 03/19 22:20

→ jk21234:把時間花在針對cache最佳化就好..... 03/19 22:20

→ jk21234:甚麼時候寫程式的人要管這問題.我推斷: 1.PS3/360正式發 03/19 22:21

→ jk21234:售的遊戲的開發者 2.nVidia/ATI/Sis/VIA/Intel的RD 03/19 22:22

→ jk21234:3.寫出來的程式需要Top500等級的電腦來執行的人 03/19 22:22

推 nvidia:還有data width的問題 03/19 22:27

推 RolfP:樓下你略懂嗎? 03/19 22:27

→ nvidia:不過很多人連這個都不知道就當程式RD了 很慘很慘 03/19 22:27

→ ricky7899:頭到尾指有一篇測試文 就做這一堆延伸好沒意義 03/19 22:27

→ ricky7899:更別說測試一定準? 03/19 22:28

→ ricky7899:有測試過的應該多少都知道 記憶體測試是最不準的吧 03/19 22:29

→ StarHero:能不能舉一個應用面的例子呢 03/19 22:31

推 three456:好強 推 03/19 22:35

推 ting35:推專業~~看無 Orz 03/19 22:35

推 kkkkkkq:快取最佳化 這裡的快取是指CPU上的快取 還是還有其他? 03/19 22:49

推 maniaque:SIS 在記憶體效率這一塊很弱呀......... 03/19 22:49

→ maniaque:從P3 時代就很弱了(SIS630T約是I810E2 的...六成吧..) 03/19 22:50

→ maniaque:跑 memtest86+ 時,看到那種水準真的"軟了" 03/19 22:51

推 batschris:推專業 03/19 23:01

推 ReDmango:幹簡化過後我的大腦還是好痛阿XDDDDDDDDDDDDDDDDDDDDDDDD 03/19 23:04

推 lsslss:未看內文 jk神就要先推一下 03/19 23:14

推 yoyodawning:推 03/19 23:17

推 ricky7899:原來我推錯篇文章了 剛那推文是該推上一篇的 03/19 23:22

→ ricky7899:這篇 哪有我說話的餘地阿~~~ 太專業了只能推阿 03/19 23:22

推 PhenomII950:有神快拜!!! 03/19 23:34

推 wch6858: 03/19 23:42

推 StarHero:有點懂了 推專業~ 03/19 23:43

推 check:專業 03/19 23:50

推 softwind:可是原原po的問題是 why controller沒變化 不是sw最佳化 03/19 23:54

推 tonyhsie:所以就是row-major跟column-major的選擇嗎? 03/19 23:56

推 ebolalala:隔了兩個小時再看一遍還是不懂 內文變更多了~~~~~ 03/20 00:01

推 pkmu8426:了解重點為何了 不過專有名詞統統看無Q Q 03/20 00:13

推 check:因為比起controller，不如把prediction做好更重要 03/20 00:20

→ check:另外編譯器好像也會針對不同處理器，安排變數/指令儲存位置 03/20 00:21

→ check:讓它讀寫更有效率 03/20 00:21

推 polomaster27:推樓上，講到prediction又可以扯到很多 03/20 00:32

→ Shockedtopee:非人類，太難懂... 03/20 00:36

推 korsg:真強者...看的頭都暈了,果然理論跟實際有很大差距xd 03/20 01:57

推 leubaga: 03/20 01:57

推 maplemeowcat:jk神又出來了快推一個 03/20 03:41

推 CHOCOLA1983:啊哈哈哈我看不懂 (￣▽￣) 03/20 09:28

推 superLM:只看得懂改車的例子XD 03/20 09:42

推 ArSaBuLu:推專業 只看得懂改車的例子+1 03/20 11:20

→ dslite:有講跟沒講一樣 03/20 11:31

推 hgtt:推 JK神 03/20 12:17

→ hgtt:我也只看懂改車例子 03/20 12:18

→ PlayStation3:淺顯易懂。 03/20 12:50

推 check:沒錯！latency hidden在CUDA等平行運算是相當重要的問題 03/20 18:07

推 leojdh:controller的最佳化有時還牽涉IP授權問題, 很多不是做不到. 03/20 20:24

→ leojdh:再來OS對SW那些要做怎樣的cache最佳化也是一大問題. 03/20 20:25

→ leojdh:所以跑分雖然可以參考, 但不能盡信, 差太多要找出原因. 03/20 20:26