Merom T7400 VS Yonah T2600

goldie

初級會員
已加入
6/4/05
訊息
17
互動分數
0
點數
0
感嗯…
美儂的快取真是進步不少啊 @_@... (物慾指數上升ing...)

綠色那條線是怎麼一回事 XD (爆)
 

coolaler

FANGBING LO (Robinson Lo)
已加入
9/17/03
訊息
53,151
互動分數
635
點數
113
位置
Taichung
網站
www.coolaler.com
goldie 說:
感嗯…
美儂的快取真是進步不少啊 @_@... (物慾指數上升ing...)

綠色那條線是怎麼一回事 XD (爆)
Green line是Merom的頻寬
 

goldie

初級會員
已加入
6/4/05
訊息
17
互動分數
0
點數
0
一個擷圖的建議: ;face0;
拍「沒有很華麗」的畫面
PNG 會比 GIF 更小,而且PNG是「無失真」壓縮的 (Gif、jpg 為失真壓縮)
看起來更美

試試看嚕… ;em03;
推薦一個擷圖 freeware(英文): Screenshot Captor
可擷部份畫面、加入文字、畫方塊、圈圈…等等

--
遊戲、桌布是照片、照片,等相異像素較多較複雜的,存 jpg 效果不錯
 

coolaler

FANGBING LO (Robinson Lo)
已加入
9/17/03
訊息
53,151
互動分數
635
點數
113
位置
Taichung
網站
www.coolaler.com
goldie 說:
一個擷圖的建議: ;face0;
拍「沒有很華麗」的畫面
PNG 會比 GIF 更小,而且PNG是「無失真」壓縮的 (Gif、jpg 為失真壓縮)
看起來更美

試試看嚕… ;em03;
推薦一個擷圖 freeware(英文): Screenshot Captor
可擷部份畫面、加入文字、畫方塊、圈圈…等等

--
遊戲、桌布是照片、照片,等相異像素較多較複雜的,存 jpg 效果不錯
感謝告知
截圖程式我都有
擷部份畫面camera4也很好用
不過我習慣抓整個螢幕 :D
png倒是個好建議

:)

cache2.png
 

痞嘻哈

初級會員
已加入
4/25/06
訊息
25
互動分數
0
點數
0
C大:
請問AOPEN I975XA YDG 完全支援 Merom 嗎?
還是須先用Yonah 至 AOPEN 更新 BIOS?
 

coolaler

FANGBING LO (Robinson Lo)
已加入
9/17/03
訊息
53,151
互動分數
635
點數
113
位置
Taichung
網站
www.coolaler.com
痞嘻哈 說:
C大:
請問AOPEN I975XA YDG 完全支援 Merom 嗎?
還是須先用Yonah 至 AOPEN 更新 BIOS?
要更新新的BIOS才會支援Merom
 

jasonyang

初級會員
已加入
1/24/06
訊息
14
互動分數
0
點數
1
itany 說:
我贊同您的結論和觀點
如果我沒有記錯,P M (含Yonah)L2都是128bit寬度,而P4是256bit。但是,考慮到P4的L1太小,L2應該做的快一些。
而且,AMD的K7/K8有重要的缺陷。雖然K8是3組ALU,比較Yonah多了1組,但是K8在讀入操作數的時候發動的比Yonah要晚得多,以至於不能及時地把數據讀入L1,使得ALU得不到數據而閒置!同時,如果内存延遲(latency)較大,如DDR2,那麽ALU延遲的就更多,以至於帶來災難性的後果!這就是AM2平臺性能沒什麽提升的重要原因! ;tongue;

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=2
P-M L2 width 是 256bit,相形之下 K8 只有 128bit,而 k7 更只有 64bit,在頻寬上顯得不足,我想這是 K8 架構上比較不足的地方,可能也是 k7/k8 加大 L2 cache 性能提升不明顯的原因之一。

至於讀入 operand 太慢,我想 pipeline 的設計,不管是在哪個 stage 由讀入 operand 跟 pipeline stall 幾乎沒什麼關係,因為:
1) pipeline 架構講求的是最後發出的指令,所以不管在哪個 stage 由記憶體載入根本是無關的,stall 的 cycle 是由記憶體或 cache 載入所花的時間在算的。就算 p4 高達 31-stage pipeline,也不會有人質疑其載入 operand 的 stage 先後。
就算無法了解為何無關,
2) 相較於 pipeline stage 的 "幾個" 週期數差異,由記憶體載入 L1/L2 的時間可能高達上百甚至上千個 cycle,根本微不足道。如果說從 L1/L2 載入,則可能需要數個到數十個 cycle,影響也是不大。
3) 況且 cache 還有 prefetch 的機制存在。

K8 的微架構上,明顯不如 core 的應該在於 SSE 單元只有兩組,而 core 確有三組,另外就是 1-cycle 128bit SSE,而 k8 卻是切成兩個 64bit SSE 需要兩個週期來做運算。
另外一個是在解碼器,core 是一個 complex(最多 4 uops) 與三個 simple (1 uop)成 4-1-1-1,而 k8 採用 3 個 complex (每個最多 2 uops),是 core 最多可解碼 4 個 x86 指令,而 k8 只有 3 個。
在 Load/Store 單元上,core 也比 k8 多了一組。
另外 memory disambiguation 使得記憶體可以預先載入,甚至是 out-of-order,使得這個才真的能使得 stall 減少(而不是在哪個 stage 載入 operand,但其實減少的週期數比起載入 stall 微乎其微,但總是減少了),也是 k8 所缺乏的。

總歸 core 採用比 dothan/yonah 與 k8 更寬的架構處理指令,這才是性能會超越 k8 的主因,並不是比較早的 pipeline stage 讀取記憶體晚了幾個 cycle。
 
最後編輯:

jasonyang

初級會員
已加入
1/24/06
訊息
14
互動分數
0
點數
1
舉一個簡單的例子:
假設 core 14-stage pipeline 在第 4 個 stage 載入 operand,而 k8 12-stage pipeline 在第 8 個 stage 載入 operand,就算 core 在第 4 個 stage 載入 k8 在第 8 個晚了四個才載入,但最後還是該跑完其 14- 與 12-stage pipeline,才完成一個指令,花在 pipeline stage 的 cycle 都一樣是 14 與 12(因而於在哪個 stage 無關),而 pipeline stall 的時間都是從 memory/cache 載入所花的時間。
反倒是 AGU 只有兩組的 core 計算記憶體位址可能比較慢呢!!! (k8 有三組 AGU)
 

itany

一般般會員
已加入
4/20/06
訊息
56
互動分數
0
點數
0
jasonyang 說:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=2
P-M L2 width 是 256bit,相形之下 K8 只有 128bit,而 k7 更只有 64bit,在頻寬上顯得不足,我想這是 K8 架構上比較不足的地方,可能也是 k7/k8 加大 L2 cache 性能提升不明顯的原因之一。

至於讀入 operand 太慢,我想 pipeline 的設計,不管是在哪個 stage 由讀入 operand 跟 pipeline stall 幾乎沒什麼關係,因為:
1) pipeline 架構講求的是最後發出的指令,所以不管在哪個 stage 由記憶體載入根本是無關的,stall 的 cycle 是由記憶體或 cache 載入所花的時間在算的。就算 p4 高達 31-stage pipeline,也不會有人質疑其載入 operand 的 stage 先後。
就算無法了解為何無關,
2) 相較於 pipeline stage 的 "幾個" 週期數差異,由記憶體載入 L1/L2 的時間可能高達上百甚至上千個 cycle,根本微不足道。如果說從 L1/L2 載入,則可能需要數個到數十個 cycle,影響也是不大。
3) 況且 cache 還有 prefetch 的機制存在。

K8 的微架構上,明顯不如 core 的應該在於 SSE 單元只有兩組,而 core 確有三組,另外就是 1-cycle 128bit SSE,而 k8 卻是切成兩個 64bit SSE 需要兩個週期來做運算。
另外一個是在解碼器,core 是一個 complex(最多 4 uops) 與三個 simple (1 uop)成 4-1-1-1,而 k8 採用 3 個 complex (每個最多 2 uops),是 core 最多可解碼 4 個 x86 指令,而 k8 只有 3 個。
在 Load/Store 單元上,core 也比 k8 多了一組。
另外 memory disambiguation 使得記憶體可以預先載入,甚至是 out-of-order,使得這個才真的能使得 stall 減少(而不是在哪個 stage 載入 operand,但其實減少的週期數比起載入 stall 微乎其微,但總是減少了),也是 k8 所缺乏的。

總歸 core 採用比 dothan/yonah 與 k8 更寬的架構處理指令,這才是性能會超越 k8 的主因,並不是比較早的 pipeline stage 讀取記憶體晚了幾個 cycle。

對您的有的看法,我想同您交流一下。
實際上,您所說的在任何stage都可以讀入的説法是不正確的。凡是涉及到讀寫内存的操作,比如ADD EAX [1000],將内存地址為1000的操作數(operand)加到EAX寄存器(register)上,將被拆分成讀入和加法兩個微操作。只有讀入完成之後,數據已經存在于處理器内部,加法才會被發射到ALU進行運算。否則一旦出現不命中的情況,指令就會堵塞ALU,使運行不能進行。正如文章中所示,k8讀取發動時間相對于Core/P M更晚,一旦L1不能命中,L2的延遲會阻止micro-ops及時進入ALU,而且調度(scheduler)的緩存是有限的,以及數據的關聯性,導致了後續指令也不能夠及時地執行,造成效能的低下。至於您說的内存的延遲很長,但是事實上内存的延遲大概在幾十個周期,也並不算太長,而且一般情況下數據都會在L2�面,不用太關心内存的情況。
對於您提到的P4,也就是Netburst和Prescott,存在比k8更加可怕的問題。因爲他的流水綫更加長,加上採用分佈式調度,因此沒有辦法及時生成要讀取的内存地址,因此不能保證數據準備好之後才准許micro-ops進入流水綫,因而一旦出現數據沒有讀入的情況,指令就會被錯誤的執行。在其完成之後,通過判斷機制將其作廢,而通知流水綫從新執行這條指令!要浪費數十個甚至是上百個周期!這個特性被稱爲replay,是一個駭人聽聞的秘密!是最近同學推薦我看了文章才知道的!從此更加鄙視P4了!
memory disambiguation 的作用,也許被您輕視了。Core可以禦覽到96個ROB單元,因此最多可以提前幾十個周期下達讀取的操作。這一點幾乎可以將内存延遲完全消除!Intel之所以不集成内存控制單元,就是因爲北橋到處理器之間的區區幾個周期可以被良好的抵消。如果Intel集成了MC,AMD會死得更慘。反正Tulsa Itanium 就要集成FB DIMM的MC了……
您指出來的AMD的額外的AGU,實際上並不能起到多大的作用。需要同時生成3個地址的情況非常罕見。讓我們再看AMD和Intel的發射口的佈局:Intel是ALU/FPU/SSE公用發射口,AGU單獨的發射口,而AMD是ALU/AGU共用,FPU/SSE共用。顯然,整數會與地址衝突,而浮點/整數處於一邊忙碌/一邊清閒的狀態。
 
▌延伸閱讀