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

[littleshan (我要加入劍道社!)]

: 但是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)
→ Asprit:高手啊 我完全沒有看 太長 XD
推 breadf:推 配合湯姆薯叔對HT技術的解析 就可以一目了然了
→ breadf:不過看湯薯叔的評論 把HT移植到双核上反而有困難
→ breadf:甚至是效能不增反降?
推 Dopin:我太感謝 l 兄了 > < 說到 Code 維護 OO 因而出現
推 newpal:◆ 這一篇文章值 1000 銀 XD
推 ithinkurdumb:寫的狠詳細又容易懂 :D
推 singy:謝謝解惑
※ 編輯: littleshan      來自: 140.112.244.211      (06/11 02:18)