Merom T7400 VS Yonah T2600
- 主題發起人 coolaler
- 開始日期
一個擷圖的建議： ;face0;
拍「沒有很華麗」的畫面
存 PNG 會比 GIF 更小，而且PNG是「無失真」壓縮的 (Gif、jpg 為失真壓縮)
看起來更美
試試看嚕… ;em03;
推薦一個擷圖 freeware(英文): Screenshot Captor
可擷部份畫面、加入文字、畫方塊、圈圈…等等
--
遊戲、桌布是照片、照片，等相異像素較多較複雜的，存 jpg 效果不錯
拍「沒有很華麗」的畫面
存 PNG 會比 GIF 更小，而且PNG是「無失真」壓縮的 (Gif、jpg 為失真壓縮)
看起來更美
試試看嚕… ;em03;
推薦一個擷圖 freeware(英文): Screenshot Captor
可擷部份畫面、加入文字、畫方塊、圈圈…等等
--
遊戲、桌布是照片、照片，等相異像素較多較複雜的，存 jpg 效果不錯
前幾kb Block 真是爆高的 :MMM:
itany 說：
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。
最後編輯：
舉一個簡單的例子：
假設 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)
假設 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)
jasonyang 說：
對您的有的看法，我想同您交流一下。
實際上，您所說的在任何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共用。顯然，整數會與地址衝突，而浮點/整數處於一邊忙碌/一邊清閒的狀態。
