PTT數位生活區 / hardware (電腦硬體)

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

看板hardware (電腦硬體)作者 (我要加入劍道社!)時間19年前 (2005/06/08 04:03), 編輯推噓6(6推 0噓 14→)
留言20則, 3人參與, 最新討論串2/4 (看更多)
[deleted] : -- : 推 shiunlin:請問何謂"不用的指令集模擬成另一個 CPU"? 140.113.196.166 06/08 要講HT 不得不先說明superscalar superscalar是在pentium時就有的技術 它的原理很簡單：在cpu內塞入更多的運算單元 這麼一來cpu就有能力同時處理多個指令 比如說以下的assembly code imul esi, edi add eax, ebx add ecx, edx 乍看之下，cpu會先做完乘法再繼續做下面兩個加法 但事實上 只要cpu內有兩個加法器和一個乘法器 這三個指令可以「同時」進行 當然乘法比加法慢 所以效能不會變三倍 但理論上仍有很可觀的增加 (真實的情況更複雜些...指令會先被拆成更小的指令後才進入pipeline) (不過就先這麼說明吧) 然而事實並沒有這麼單純 上面的三個指令可以同時執行 是因為這三個指令沒有相依關係 如果是這樣的程式 add eax, ebx add eax, ecx 第二個指令就必需等第一個結束後才能繼續 所以第二個加法器就英雄無用武之地了 不幸的是 有寫過程式的人都知道 這種情況才是常態 也就是說 現在的cpu雖然加入了更多運算單元 可是平均起來 它們的使用率根本還不到一半 所以hyper threading的想法出現了 (學術一點的說法叫SMT) 它的想法是在cpu內塞入另一組暫存器 然後假裝自己是兩顆cpu 只要作業系統支援多cpu 就可以同時餵兩支process給它 由於兩支process的指令一定是不相依的 所以可以提高這些運算單元的使用率 連帶地整體效能也提高了 SMT本身是很好的想法 而且並不如Dopin大所說 只有一個process時會被限制只有50%的cpu resource 事實上 擁有良好instruction parallelism的程式 在單一process的情況下 還是能發揮cpu接近全部的運算能力 但是intel本身對SMT的實作有一些問題 導致hyper threading沒有發揮應有的效能 甚至有時候反而變慢 不過我本身不是學這方面的 所以並不是很清楚是怎樣的問題 有興趣的人可以去看anandtech的一篇文章 講得很仔細 http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2419&p=4 -- DO NOT disturb my programs! -- From Archimedes' last word, and may be my last word. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.244.211
推
203.70.65.28 06/08, , 1F
如果程式本身就支援多緒 就沒有幾 % 的問題
203.70.65.28 06/08, 1F
→
203.70.65.28 06/08, , 2F
我想我原文要改一下 感謝 l 兄提醒 :)
203.70.65.28 06/08, 2F
→
203.70.65.28 06/08, , 3F
良好的程式結構 也可以最佳化使用 平均於指令
203.70.65.28 06/08, 3F
推
203.70.65.28 06/08, , 4F
看來造成誤解 我改成 "最糟的狀況下" 比較不會誤會
203.70.65.28 06/08, 4F
推
61.224.134.53 06/08, , 5F
你的例子中 add eax,eba 換行 add eax,ecx
61.224.134.53 06/08, 5F
→
61.224.134.53 06/08, , 6F
如果分兩組register來計算最後還是要丟回到某個EAX
61.224.134.53 06/08, 6F
→
61.224.134.53 06/08, , 7F
所以這種情況效能就沒有增加.....
61.224.134.53 06/08, 7F
→
61.224.134.53 06/08, , 8F
我的第一行eba應該是ebx....
61.224.134.53 06/08, 8F
→
61.224.134.53 06/08, , 9F
這種情況很常見 所以現在的HT技術因為程式沒有針對
61.224.134.53 06/08, 9F
→
61.224.134.53 06/08, , 10F
HT技術作最佳化才會這樣 我想應該不會有人這麼無聊
61.224.134.53 06/08, 10F
→
61.224.134.53 06/08, , 11F
為了intel的HT技術做程式最佳化吧......
61.224.134.53 06/08, 11F
推
61.224.134.53 06/08, , 12F
我在想 是不是在高階語言轉低階語言的過程中
61.224.134.53 06/08, 12F
→
61.224.134.53 06/08, , 13F
因為編譯器幫忙加了很多不必要的處理 造成一隻大
61.224.134.53 06/08, 13F
→
61.224.134.53 06/08, , 14F
project在執行上多少降低其效能?
61.224.134.53 06/08, 14F
→
61.224.134.53 06/08, , 15F
單純的用組語來寫應該能達到高度優化程式的效果..?
61.224.134.53 06/08, 15F
推
203.70.65.28 06/08, , 16F
組語要寫得結構化才會比較 OK 之後還有優化
203.70.65.28 06/08, 16F
→
203.70.65.28 06/08, , 17F
有些工具還頗好用的 以前在 TASM/MASM 時代常用的
203.70.65.28 06/08, 17F
※ 編輯: littleshan 來自: 140.112.244.211 (06/08 20:17)
推
140.112.25.140 06/09, , 18F
比如 icc 一定會對 HT 做最佳化啊
140.112.25.140 06/09, 18F
→
140.112.25.140 06/09, , 19F
此外，現在人寫的組語未必比 compiler 寫的快
140.112.25.140 06/09, 19F
→
140.112.25.140 06/09, , 20F
編譯器是為了一般性，一定有一大堆不必要的東西
140.112.25.140 06/09, 20F
‣ 更多 littleshan 的文章
文章代碼(AID): #12fVsfTr (hardware)
hardware 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 littleshan 的文章
文章代碼(AID): #12fVsfTr (hardware)