HT真的有增進多工效能嗎?未必..(P4 3.0E測試)

[funyelin]

有可能喔 ! 之前不是有新聞說 AMD 引進 Dual Core 的 K8 時弁茈i望低於 100W ? 大大的
想法不無可能 ! 反觀 Intel 的 " 據說 " 會很 " 輕鬆 " 的突破 200W .... 還被討論了一陣子...
:P

 

[134217728]

大家的討論都好深奧，小弟是沒這方面的知識，所以只簡單PO一下我用HT的感覺，跑SETI測試，是大約的平均，我有用SETI Spy紀錄每個跑完單位所花費的時間，不過我的測試法是：
1.開HT跑一次只一個WU
2.開HT一次跑兩個WU
第1點的方式不知是否跟關HT跑一個WU的結果一樣，但我總是懶得重開機去調BIOS，所以只用這樣的方式模擬。

當時的測試配備簡述：
P4 3.06@23*141=3254MHz
G-SKill DDR400@DDR352 2.5-3-3-7 512MB*2
Epox 4PDA2V
SETI Monitor with CMD 3.08版；SETI Spy with CMD 3.08版
1.開HT跑一次只一個WU需時2.5小時。
2.開HT一次跑兩個WU需時3.5小時但有兩個結果，平均為1.75小時。

現在改裝備成為：
P4 3.40@17*201=3420MHz
G-SKill DDR400@DDR403 2.5-3-3-8 512MB*2
Epox 4PDA2V
SETI Driver with CMD 3.08版*2；SETI Spy一起監視*1；BT Spirit下載微干擾
1.開HT跑一次只一個WU未測試，因最近在趕成績，暫時不測這理論上會較慢的。
2.開HT一次跑兩個WU需時3.2小時但有兩個結果，平均為1.6小時。
其實我發現SETI Driver較SETI Monitor會干擾CPU使用率，加上在跑BT，所以成績的進步上看起來沒有大躍進的感覺。

不過這樣的結果不能完全證明HT有增加效能，今天晚上打算測另一台沒HT的P4 2.4BG的，環境為：
SETI Driver with CMD 3.08版*2；SETI Spy一起監視
無HT一次跑一個WU
無HT但一次跑兩個WU
因要多跑幾個WU才能知道大約平均植，到時候再來PO結果。

另外我找了一篇關於HT的文章，有圖解說，也蠻容易看得懂的：
HKEPC介紹Hyper-Threading原理分析

 

[thorr]

看完這個主題
才知道小弟我才疏學淺同時附加頭昏眼花 :PPP:
但還是很努力的看完了
大致上了解INTEL與AMD技術差異與發展歷史
真的讓我獲益良多 :lkl:

 

[funyelin]

哈哈哈 , 只是教學相長 , 各有所長罷了 . 在下是對 P5 發展到現在的 P4 EE 演變史稍有研究罷了
, 不然 San 大來的深奧 ( 說實話 , 有些真的在下也看不懂... 惡補中 ~~ :ph34r: ) .
比起小白天堂或 XXDVD 的 , 這種只有討論沒有爭論的還真是不多 . 真的像某版大的名言 : 討論
區的良好風氣靠你我共同維持 ! :D

 

[funyelin]

Originally posted by Sander+Aug 9 2004, 07:16 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (Sander @ Aug 9 2004, 07:16 PM)</td></tr><tr><td id='QUOTE'> <!--QuoteBegin-dauzone@Aug 9 2004, 06:26 PM

過短的pipeline stage

短雖短也是有好處的歐，傳輸時間變的比較短阿.

嗯嗯...其實講"過短"是不太對的
記得以前有看過一篇研究
說是以最常使用到的一些x86指令來做模擬
在可以做到的分支預測準確度之下
最適合的Stage深度應該是在8個stage左右

不過以現在的半導體製程可以看到
利用超大的cache來提高命中率並不是難事
可以使很長的管線一樣保持不錯的執行效率

短的管線深度
最明顯的好處便是在發生hazard的時候
比如說是塞在同一個pipeline裡的兩個指令同時對記憶體做存取
這樣便會發生hazard
其實有很多的研究都在想辦法避免hazard的發生..
或是在hazard發生之後用一些方法去recover
但是這些都太過複雜
以我所知
目前不論是Intel或是AMD的處理器都是倚賴分支預測的準確度
儘量去schedule出沒有dependency的順序來執行
這也就是x86的superscalar處理器中OOO(Out-Of-Order)的精華所在
萬一不幸還是發生了hazard
惟一的方法就是只能把塞在管線中的指令全部清掉重新再來

想想看如果已經塞到最裡面的那一道指令出了問題
Prescott就得清掉31條指令
Northwood就得清掉20條指令
K7則只會清掉12(10?)條指令
長管線的處理器會受到比較大的效能損失
短管線的處理器相對之下就比較有優勢

但短的管線也並非都沒有壞處
壞處就是工作沒有像長管線處理器那樣分的那麼細
每一個stage需要做比較多的事情
如果沒有製程提升的幫忙
可以到的頻率就沒有長管線那麼高

可以看的出來
長管線處理器的分支預測準確度對其效能非常重要
而分支預測需要大量的cache來儲存Prediction的history
這也就是為什麼Intel的Willamate(L2=256KB?128KB?)轉到Northwood(L2=512KB)的時候
效能可以有明顯的大躍進
但是AMD的T-bred(L2=256KB)轉到Barton(L2=512KB)的時候
卻沒有那麼明顯的差異

以上是小弟的一些見解跟大家拿出來討論討論
如果有說錯請各位版友不吝指正! [/b][/quote]
所謂的兩個指令同時存取一條 Pipeline 的時候沒記錯的話叫 " 執行序相依 " 吧 ? 這時候需要一個
仲裁出面解決哪個指令先跑 , 哪個指令延後 . 不過這又跟分支預測習習相關 , 所以還是多多提升
分支預測的命中率比較好吧 ? 至於 Out of Order 沒記錯的話叫 " 超車執行 " , 就是當 A 指令要
進入 Pipeline 的前一刻 , 突然 B 指令要 " 插隊 " 時可將順序轉換一下讓 B 指令先跑 , A 指令在
後 . 但就程式設計的觀點來看 , 這種情形還是少發生的好 ! 雖說具備 Superscalar ( 中譯 : 超純
量執行 ) 的 CPU 都可以這樣做 , 但是一個真正優秀的程式設計師是要避開這種情況免得 Pipeline
三不五時就塞住 , 又要花幾個時脈週期清除再重新執行 ! 當然 , 大量的 L2 Cache 有助於減少這
種情況的發生 ! 同樣的情況在 K8 上的差異就十分明顯了 : L2 512KB 的程式執行效率就是無法
超越 1MB 的 ! 不過這又跟分支預測的演算法有關係 , 同樣的情形在 Northwood 和 Prescott 的
差異就不若 K8 的大 ! 所以由此可推測出 : K8 的分支預測命中率遠高於 Prescott 不是沒有道理
的 !

 

[joeyf40]

真正的雙CPU真的很好用.之前用兩顆2500+超2.4G.可以同時做好多工作.而不會LAY.可惜主板被我超到掛了.現在用單CPU還真的有點不習慣.

 

[Sander]

Originally posted by funyelin@Aug 11 2004, 05:57 PM
所謂的兩個指令同時存取一條 Pipeline 的時候沒記錯的話叫 " 執行序相依 " 吧 ? 這時候需要一個
仲裁出面解決哪個指令先跑 , 哪個指令延後 . 不過這又跟分支預測習習相關 , 所以還是多多提升
分支預測的命中率比較好吧 ? 至於 Out of Order 沒記錯的話叫 " 超車執行 " , 就是當 A 指令要
進入 Pipeline 的前一刻 , 突然 B 指令要 " 插隊 " 時可將順序轉換一下讓 B 指令先跑 , A 指令在
後 . 但就程式設計的觀點來看 , 這種情形還是少發生的好 ! 雖說具備 Superscalar ( 中譯 : 超純
量執行 ) 的 CPU 都可以這樣做 , 但是一個真正優秀的程式設計師是要避開這種情況免得 Pipeline
三不五時就塞住 , 又要花幾個時脈週期清除再重新執行 ! 當然 , 大量的 L2 Cache 有助於減少這
種情況的發生 ! 同樣的情況在 K8 上的差異就十分明顯了 : L2 512KB 的程式執行效率就是無法
超越 1MB 的 ! 不過這又跟分支預測的演算法有關係 , 同樣的情形在 Northwood 和 Prescott 的
差異就不若 K8 的大 ! 所以由此可推測出 : K8 的分支預測命中率遠高於 Prescott 不是沒有道理
的 !

嗯...其實我也有點忘記了..謝謝funyelin大的指正

印象中Out-Of-Order的出生
是因為從486開始..Intel引進了2條以上的pipeline來同時執行以提高效能
但多條pipeline如何保持好的效率便是一個難題
像x86架構的處理器多以superscalar來解決問題
意即使用hardware來做instruction的dispatch
而OOO則是superscalar中最為先進的一種演算法
可以在instruction還沒有進pipeline的時候
找出有dependency的部份..
也就是有可能會發生hazard的部份
然後將這些可能發生衝突的instructions排開
以提高執行的效率
因此instructions進入pipeline的順序和程式中不同
便叫做"亂序執行"
這也是當今X86處理器中最花transistor,最複雜,也是最耗電的一部份

而像是Transmeta的處理器使用VLIW的架構
便是以另外一種形式去實現多管線執行
VLIW(Very-Long Instruction Word)中譯做超長指令字
意即會使用軟體compiler
在程式譯成CPU可以看的懂的低階語言的同時也做好上述scheduling的動作
這樣的好處就是省下了那一大堆的hardware superscalar的transistor
所以Transmeta的CPU才會Die size又小又省電
而且若是將程式經過對CPU最佳化過的compiler去compile
效能便會非常好
但反之若沒有去重新用optimized過的compiler去compile
效能就比較差了..
Intel的Itanium就是一個最好的例子
而Transmeta除了採用VLIW..另一個最厲害的地方
便是其利用Code Morphing的技術
讓RISC核心的CPU可以執行x86的程式
不過轉譯的過程也損失了一點效能就是了
再講下去可能就偏離正題了..呵

而分支預測應該是當CPU遇到程式中指令很深的分支判斷時
會先根據之前執行過的判斷
然後透過演算法去算出這個分支最有可能去走的path
便繼續執行下去
如果判斷是正確的..便gain到了搶先執行的時間
如果判斷是錯的..只好回到分支的那一點
再走對的那一條path
所以分支預測的判斷對於CPU效能的影響也是非常巨大的!

 

[CoolSilver]

很棒, 又有深度的討論
值得一推~ :)

 

[plove]

Originally posted by funyelin@Aug 11 2004, 05:43 PM
哈哈哈 , 只是教學相長 , 各有所長罷了 . 在下是對 P5 發展到現在的 P4 EE 演變史稍有研究罷了
, 不然 San 大來的深奧 ( 說實話 , 有些真的在下也看不懂... 惡補中 ~~ :ph34r: ) .
比起小白天堂或 XXDVD 的 , 這種只有討論沒有爭論的還真是不多 . 真的像某版大的名言 : 討論
區的良好風氣靠你我共同維持 ! :D

這個討論區真的不錯
唯一美中不足的是，還是充滿了對INTEL有極度恨意的網友
一堆人只要一提到INTEL的產品，就一昧的漫罵和幹瞧，已經失去討論的意義
在台灣網路上大多數的硬體站台，都已經被那種極度恨INTEL的網友給佔據，不知道大家同不同意？


希望站大能夠注意一下這種情況，不要讓這邊也讓那些充滿恨意的網友給佔據。
不常發言，只是提供個人建議。
也希望這個討論區能夠越來越好。

 

[funyelin]

其實平心而論 , 在下也對 Intel 的做法感到有點不以為然 . 最主要的原因是 Intel 的產品真的
太過高價 , 要跑出高效能者需要不少硬體搭配才行... CPU 從 S423 到現在看不太到有什麼改
進的地方 ( 惟一增加的大概就是 SSE3 和 HT 還有 200 外頻吧 ? 其餘的還是一樣 , 靠製程提升時
脈和加大 Cache 和設法降低 Vcore 來解決 ) ! 當初 HT 剛問世時給人一種高不可攀的感覺 !
因為 533 FSB P4 中惟一具備 HT 的只有 3.06G 那一款 ( 在 200 外頻 = 800 FSB P4 出現前
是如此... ) ! 但是當時 3.06G 的 P4 價格真的是天價 ( 沒記錯的話要兩萬台幣 ) ! 又當時最強的
Chipset 是 845PE , 主機板也是不便宜 , 造成 HT 給人的印象就是 " 貴 " ! 後來 200 外頻的 CG
出來後才打破這種局面 , 君不見 CG 一問世後 3.06G 就像是從人間蒸發一樣可說幾乎消失了 ?
就是為了避免自家人打自家人的局面發生 ! 算是 Intel 的政策使然吧 ? 再者 , P4 由於那長達
31 Stage 的 Pipeline ( Northwood 是 20 Stage ) 對於 Game 的執行效率非常不利 ! 而且
SSE2 和 SSE3 都是針對較為 Pro 的場合才有利 , 對於 Game 的執行效能增益可說是微乎其微 !
現在的 Game 可不是一個 Programer 就搞的起來... 所以由一群人一起設計時一定要協調好 ! 就
像是兩人三腳不同步就會跌倒一樣 , 綜合起來給人的感覺就是 P4 在 Game 平台效能不彰的情況
! 這也是為什麼版上很多新手說要裝台玩 Game 的主機時很多人都會推薦 K8 的原因 ! 因為 K8 的
表現實在是沒話講 , 在下也是親身體驗到才敢這樣說的 ! 不過 P4 在 Game 上表現雖然不若 K8
出色 , 但在 DivX/MPEG4 影像轉換方面可是 K8 望塵莫及的地方 ! 剛剛在下提到較為 Pro 的場合
便是在此 , 影像轉換可是 P4 的拿手好戲 ! 聞道有先後 , 術業有專攻 ! 平時一般使用者在用的話 ,
在下會推薦 K8 ! 但是若是靠影像轉換吃飯者 ( 如以攝影為業 , 常做 DVD/VCD 轉換者 ) 在下強
烈推薦 P4 ! 當然 P4 EE 則會更好喔 ! 視財力而為吧 !