PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   系統組件 (https://www.pcdvd.com.tw/forumdisplay.php?f=19)
-   -   AMD公佈新一代理器K8L細節 (https://www.pcdvd.com.tw/showthread.php?t=621122)

everspiral 2006-05-17 09:10 PM

引用:
作者艾克萊爾
K8-L 的"L"就是指4核

如果雙核就是X2系列,還蠻好記的阿 :confused:



改名叫X4不就得了

這個架構跟OPTERON新版的架構又有些不同
難道說OPTERON跟ATHOLON64分道揚鑣了
以後應該就不會再有少一隻腳的OPTERON了

superscalar 2006-05-17 10:04 PM

引用:
作者sutl
果然L2無法做共享式架構 :flash:

自K7起,為了提高快取命中率,L1有的資料L2就不會有,讓快取浪費減至最低,K8自然承襲這項設計。

intel一直採用傳統式的設計,L1有的東西L2也會有,所以一直維持小L1也是為了避免浪費。

傳統設計到了多核心時代反而變成好東西,因為L1讀取資料後L2資料還在,所以L2可以共享不會發生事情。

而K7/K8的設計,L2就無法共享了,假設CPU1讀取了一筆資料到L1,於是L2將這筆資料刪除,然後當CPU2要同樣的資料時,發現L2沒有,於是啟動記憶體控制器去讀外部記憶體,這樣會造成性能下降。

看圖可以發現,L2快取小了很多,原本K8的L2是佔去一個核心一半以上的空間的,猜測K8L每個核心的L2大概是128KB。

說真的,這樣的設計跟intel比起來真是非常浪費,因為在同一時間四顆核心所要存取的資料其實差不多,AMD的大L1+L2的設計浪費了很多電晶體,這在四核心時代就會有點...

512KB L2 per core

superscalar 2006-05-17 10:09 PM

引用:
作者艾克萊爾
之前AMD不是才得到某項技術授權,可以把快取在同容量下縮至1/5大小嗎?
希望有用上~ :p


latency 太高
L3 專用

引用:
作者futureli
上面的寫的滿清楚的啊! 關鍵就在可以用二層的時候為什麼要用三層的快取。
我想 AMD 概念上大概是用兩組雙核再加一個 shared 的 L3 去做,才變成你形容的樣子。
可以用二層解決不用而得用三層,那就是一種浪費。所以樓上的才說可能得重新再設計成二層的架構比較好啊。


你確定用2 Level average latency 就一定會比3 level 好???
computer architecture 有讀熟嗎??

superscalar 2006-05-17 10:12 PM

引用:
作者ccc123456
k8原生設計就用了5年,現在就只在小細節上變來變去
這樣效能會提昇多少?....還是砍掉重練換k10好了


OO loads 就差很多了
還有 single cycle throughput SIMD DP FP
改好的memory controler 也會差不少

alience 2006-05-17 10:50 PM

引用:
作者sutl
首先,看這種放大圖怎麼可能知道真實面積 :p

我講的是大小比例,以前K8的L2面積比核心還大,現在比核心小那麼多,當然是因為L2縮小了啊。

至於快取頻寬share的問題,我想至少比記憶體頻寬被share好多了。

以前intel雙CPU主機板(例如440BX)共用一個北橋頻寬,那才真的是災難 :laugh:

分享式設計的優點在百核心這個想法下是有利的,因為每個核心都很小,同樣的面積可以塞入更多核心,在多線序軟體的支援下,或許L2頻寬被瓜分的缺點不會那麼明顯。

反正目前intel的想法是盡量塞核心,何時會達到性能瓶頸,大家等著看 :flash:


你指的應該是130nm L2 1M的k8 L2 cache所佔die面積超過核心吧
但是我已經很明確的告訴你
90nm Rev.E Die size 199平方釐米 L2佔81平方釐米
90nm Rev.F Die size 220平方釐米 L2佔77平方釐米
可見製程縮小對於縮小cache應該是有較大助益的
所以光用比例來猜L2大大縮小有點不合理
至於多核心share cache問題
我想除了頻寬share之外
控制存取的困難度上升造成的latency增加也是一個關鍵
就目前看到的
IBM power6和intel Itanic 2都將用deditcated L2+share L3
而非share L2
我想這些都是trade-off的問題

sxs112.tw 2006-05-18 12:11 AM



Realworld上David Kanter整理的比較詳細的detail:
0. Native quad core
1. Hypertransport up to 5.2GT/s
2. Better coherency
3. Private L2, shared L3 cache that scales up.
4. Separate power planes and pstates for north bridge and CPU
5. 128b FPUs - see 14,15
6. 48b virtual/physical addressing and 1GB pages
7. Support for DDR2, eventually DDR3
8. Support for FBD1 and 2 eventually
9. I/O virtualization and nested page tables
10. Memory mirroring, data poisoning, HT retry protocol support
11. 32B instead of 16B ifetch
12. Indirect branch predictors
13. OOO load execution - similar to memory disambiguation
14. 2x 128b SSE units
15. 2x 128b SSE LDs/cycle
16. Several new instructions

Coprocessors:
media processing
JVM/CLR acceleration
TOE, XML or SSL processing

jasonyang 2006-05-18 01:38 AM

以比例來看,AMD 似乎把 Rev. G 512MB L2 cache 做得比 Rev. F 1MB 一半還小多了,比以前進步多了,至少成本降低不少。

不過老實講 shared L3 cache 只有 2MB 感覺有點太少了(dedicated L2 512MB*4 就已經 2MB 了),應該要有 4MB 的版本。
我想應該還是用 SRAM 尚未用到 Z-RAM,感覺如果用 Z-RAM 提高到 4~8MB 比較理想,雖然 latency 可能比較高,但畢竟 512MB L2 cache 快取命中率已經夠高了,Z-RAM 用來提高能 cache 的 workset 也夠讓許多 benchmark 提升不少。像 Power5 就有巨大的 36MB L3 cache (DRAM)。

至於 on-die memory controller 似乎還是一樣是 dual-channel,沒有做到 quad-channel,或是兩個 dual-channel。

老實說我覺得 dedicated L2 + shared L3 cache 是不錯的 trade-off,解決了 shared L2 cache 在 quad-core 面臨的 latency 與 four-port 設計上的問題,導致的性能瓶頸,dedicated L2 使得每個核心有自己高速的 L2 cache,shared L3 cache 又補足不能動態 balanced 的問題。只是 2MB shared L3 cache 有點少,最好能夠多一點,尤其是用 ZRAM 達到 4MB 以上。

從 11. 與 15. 點看來,L2 cache witdh 可能提升到 256bit 了。

多一個 FPU 單元,在 SSE 與 x87 性能似乎都增強不少,可能如同 INQ 說的達到 1.5 倍。

在 IPC 上,3, 11, 12 與 13 應該能有一些提升。

k8L 雖然在省電上進步不少,可以獨立調整 P-state 與 C-state,但似乎還是不能像 core 2 一樣動態的關閉 cache,可能是因為 exclusive cache 無法做到吧?

6, 9, 10 大概只會在 supercomputer 與 high-end server 上有很大的幫助。

第 1, 2, 3 點可能對於 8P~32P server 有不小的幫助。

gibson7117 2006-05-18 02:10 AM

引用:
作者sutl
而K7/K8的設計,L2就無法共享了,假設CPU1讀取了一筆資料到L1,於是L2將這筆資料刪除,然後當CPU2要同樣的資料時,發現L2沒有,於是啟動記憶體控制器去讀外部記憶體,這樣會造成性能下降。

這時候CPU2應該是要想辦法把CPU1的該DATA抓到CPU2吧
否則DATA專一性可能不同 (若CPU1對該DATA有做運算)

gibson7117 2006-05-18 02:21 AM

引用:
作者alience
可是到4core或是更多core時share應該會出現L2頻寬上的瓶頸
因為L2頻寬也是share
除非L2頻寬一直加上去
且4core以上要做share cache的control unit應該比dedicated複雜多了
看不出AMD浪費在哪裡

嗯嗯
L2共享也有些BUS使用上的問題
CPU2使用L2時其他CPU不能使用
CPU越多的時候這問題會更嚴重吧

共不共享都是要評量的 沒有哪種架構一定完全都是優點沒缺點的

I V II III 2006-05-18 02:23 AM

引用:
作者jasonyang
以比例來看,AMD 似乎把 Rev. G 512MB L2 cache 做得比 Rev. F 1MB 一半還小多了,比以前進步多了,至少成本降低不少。

不過老實講 shared L3 cache 只有 2MB 感覺有點太少了(dedicated L2 512MB*4 就已經 2MB 了),應該要有 4MB 的版本。
我想應該還是用 SRAM 尚未用到 Z-RAM,感覺如果用 Z-RAM 提高到 4~8MB 比較理想,雖然 latency 可能比較高,但畢竟 512MB L2 cache 快取命中率已經夠高了,Z-RAM 用來提高能 cache 的 workset 也夠讓許多 benchmark 提升不少。像 Power5 就有巨大的 36MB L3 cache (DRAM)。

至於 on-die memory controller 似乎還是一樣是 dual-channel,沒有做到 quad-channel,或是兩個 dual-channel。

老實說我覺得 dedicated L2 + shared L3 cache 是不錯的 trade-off,解決了 shared L2 cache 在 quad-core 面臨的 latency 與 four-port 設計上的問題,導致的性能瓶頸,...

................... :confused:


所有的時間均為GMT +8。 現在的時間是08:28 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。