Re: [問題] Intel 3.2g 和 AMD 3500+ 939 到底괠…

看板hardware (電腦硬體)作者littleshan (我要加入劍道社!)時間19年前 (2005/06/10 02:35)推噓5(5推 0噓 3→)

留言8則, 6人參與討論串4/4 (看更多)

: 但是intel本身對SMT的實作有一些問題 : 導致hyper threading沒有發揮應有的效能甚至有時候反而變慢 : 不過我本身不是學這方面的所以並不是很清楚是怎樣的問題 : 有興趣的人可以去看anandtech的一篇文章講得很仔細 : http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2419&p=4 為了讓大家更明白我稍微念過了這篇文章以下是我的解釋如果有認何錯誤請大家不吝指正先簡單講一下p4內部執行x86指令前的過程存入指令拮取指令解碼 trace cache | | | | | | | | L2 Cache --> Decoder --> Queue --> Trace Cache --> μOp Queue | | | | 這張圖當然是經過了簡化...instruction fetch到decode之間還有一個queue 不過先暫時不提它吧每個x86指令在執行時都須要像上面那樣通過一層一層的關卡首先是從L2 Cache(假設它已經在L2了)中抓到cpu內 (instruction fetch) 指令解碼的動作會把它拆成更小的微指令 (μOp) 然後放到地位類似L1 Cache的trach cache中再進入μOp Queue 這時候才準備好讓對應的運算單元執行 x86指令屬於CISC架構所以在指令解碼的地方比較複雜 p4的instruction decoder平均兩個cycle可以生出六個μOp 這相當於每個cycle中約有兩個x86指令可以被解碼這樣的速度在單一thread的情況下是可以被接受的因為指令間有相依情況所以同時間有超過兩個指令可被執行的情況不多見但是在hyper-threading的情況下就不同了因為同時間有兩個thread在執行每個cycle解碼兩個指令就太慢了如果指令解碼的速度跟不上後面運算單元的速度那麼運算單元就必須停擺(stall)等待前面的事情先做好另一方面雖然hyper-thread多提供了一顆虛擬的cpu 但μOp Queue並沒有跟著變兩倍大也就是說 μOp Queue必須切一半來給這兩顆虛擬cpu來使用而這造成的影響就是out-of-order execution的效果變差先簡單說說什麼是out-of-order execution吧回頭看我po的第一篇文關於指令間相依造成無法平行運作的例子 add eax, ebx add eax, ecx 這兩個指令無法同時運作因為第二個指令必須先等第一個指令完成但如果這兩個指令的後面還有東西... add eax, ebx add eax, ecx add edx, esi add edx, edi 大家可以發現第一個指令和第三個指令沒有相依關係第二個和第四個也沒有所以只要把第二個指令和第三個指令對調不但效率提高結果也是正確的這就是out-of-order execution的想法 cpu只要去分析一連串的指令找出它們之間的相依關係就可以藉由重排指令順序的方式提升效能但是在hyper-threading的情況下因為μOp Queue被切了一半所以對out-of-order execution來說可以被分析的指令也少了一半產生的效果就變差了最後 hyper-threading中兩顆虛擬cpu的L1 cache是共用的但兩支thread的spatial locality並不高 (很難翻譯這個名詞^^||) 也就是cache更容易miss 上面提到的三種情況 (decode不夠快、out-of-order效果不好、cache容易miss) 都會使得運算單元停下來等待(stall) 然而 prescott為了提升時脈而有了超深的pipeline (31層pipeline stage) 對此也有一定的影響這就是hyper-threading在p4上無法有效提升效能甚至拉低效能的原因 : -- : ※ 發信站: 批踢踢實業坊(ptt.cc) : ◆ From: 140.112.244.211 : 推 Dopin:如果程式本身就支援多緒就沒有幾 % 的問題 203.70.65.28 06/08 : → Dopin:我想我原文要改一下感謝 l 兄提醒 :) 203.70.65.28 06/08 : → Dopin:良好的程式結構也可以最佳化使用平均於指令 203.70.65.28 06/08 : 推 Dopin:看來造成誤解我改成 "最糟的狀況下" 比較不會誤會 203.70.65.28 06/08 嗯我的意思是instruction-level parallelism 也就是降低指令間的相依關係提升他們被平行處理的可能性而非多緒 (multi-threading) : 推 singy:你的例子中 add eax,eba 換行 add eax,ecx 61.224.134.53 06/08 : → singy:如果分兩組register來計算最後還是要丟回到某個EAX 61.224.134.53 06/08 : → singy:所以這種情況效能就沒有增加..... 61.224.134.53 06/08 : → singy:我的第一行eba應該是ebx.... 61.224.134.53 06/08 : → singy:這種情況很常見所以現在的HT技術因為程式沒有針對 61.224.134.53 06/08 : → singy:HT技術作最佳化才會這樣我想應該不會有人這麼無聊 61.224.134.53 06/08 : → singy:為了intel的HT技術做程式最佳化吧...... 61.224.134.53 06/08 不對 add eax, ebx add eax, ecx 這種情況是「沒有對superscalar最佳化」而它很常見的原因並不是因為大家不想做最佳化而是instruction-level parallelism的最佳化很難做 HT的出現就是為了解決這個問題只要(理論上)程式可以multi-threading執行 HT就可以讓它有效能提升而把一支程式改成multi-threading 要比instruction-level parallelism要容易許多另外只要cpu有提供某些加速的機制寫軟體的人就會針對它進行最佳化這不是什麼無聊不無聊的問題而是軟體賣不賣得出去的問題 :D : 推 singy:我在想是不是在高階語言轉低階語言的過程中 61.224.134.53 06/08 : → singy:因為編譯器幫忙加了很多不必要的處理造成一隻大 61.224.134.53 06/08 : → singy:project在執行上多少降低其效能? 61.224.134.53 06/08 : → singy:單純的用組語來寫應該能達到高度優化程式的效果..? 61.224.134.53 06/08 對可是很少人這麼做因為... 1. 感覺不出差別像單純的GUI 0.01秒畫出一個按鈕和0.02秒畫出一個按鈕(多花了100%的時間!) 對使用者是沒有差別的除非他有點100個按鈕的需求... 2. 不portable 對cpu A做的最佳化不一定適用於cpu B 尤其硬體改朝換代的情況太常見了只有少數很偏執的programmer會在新的cpu推出時全部重寫他的assembly code (沒有批評的意思我一向很佩服偏執狂) 3. 最重要的問題程式是寫給人看的現在硬體愈來愈快的結果使得人們把寫程式的重心從效率轉移到彈性和維護成本上當然組合語言不會死只是全部用組合語言以提升效率的時代已經過了現在如果要用組合語言提升速度多半都是先做profiling找出效率的瓶頸然後再小部分用組合語言加速 (反正把assembly嵌入C之中是很容易的事) : 推 Dopin:組語要寫得結構化才會比較 OK 之後還有優化 203.70.65.28 06/08 : → Dopin:有些工具還頗好用的以前在 TASM/MASM 時代常用的 203.70.65.28 06/08 : ※ 編輯: littleshan 來自: 140.112.244.211 (06/08 20:17) : 推 cooller:比如 icc 一定會對 HT 做最佳化啊 140.112.25.140 06/09 不一定你的程式必須是multi-thread一起跑才能得到HT的加速但並不是所有的程式都可以multi-thread : → cooller:此外，現在人寫的組語未必比 compiler 寫的快 140.112.25.140 06/09 : → cooller:編譯器是為了一般性，一定有一大堆不必要的東西 140.112.25.140 06/09 是的 -- -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.244.211 ※ 編輯: littleshan 來自: 140.112.244.211 (06/10 04:25) ※ 編輯: littleshan 來自: 140.112.244.211 (06/10 04:29)