|
PCDVD數位科技討論區
(https://www.pcdvd.com.tw/index.php)
- 效能極限
(https://www.pcdvd.com.tw/forumdisplay.php?f=18)
- - 請問雙CPU系統，執行一般的應用程式...有差別嗎？
(https://www.pcdvd.com.tw/showthread.php?t=280861)
|
|---|
提出我自己兩台雙CPU主機的感想
1. 作業系統不支援, 白白浪費一顆CPU 2. 作業系統支援, 應用程式也支援, 這是最理想的狀況, 一個工作會同時分給兩個CPU去做, 真的可以有效減少作業時間, 作業效率大概為單CPU的1.3~1.7倍, 這種情形是完成時間比較快 3. 作業系統支援, 但應用程式不支援, 這個情形要解釋起來比較複雜, 這樣說好了, 如果我的兩顆CPU都是Athlon 1G, 跑工作A要佔用一顆CPU一分鐘的時間, 跑工作B要佔用一顆CPU兩分鐘的時間, 如果是單CPU的情形下, 同時跑AB, CPU要分配運算能量給兩個工作, AB都完成的時間不會是原來的時間(1+2 min), 而是三分鐘以上, 因為作業系統還要在兩個工作程序間切換, 也要花一些時間; 如果是雙CPU的情形下, 作業系統會把A指派給一顆CPU, 而B給另一顆CPU, 所以AB完成的時間都差不多是原來的1分鐘與兩分鐘, 所以即使只有作業系統支援而應用程式不支援, 在同時跑多個工作的情形下還是有所助益的, 最明顯的感覺, 是跑一些極耗CPU資源的程式而User又同時對硬碟作讀取動作的同時, 因為作業系統把Disk I/O的工作交給另一顆CPU去做了, 還是有感覺比較快, 這種情形下是同樣時間內可以做較多的事, 對提昇效率還是有幫助的 以上是小弟我的感受, 有錯誤請大家指正 |
引用:
說討伐太嚴重了，SMP 的確有其優點，至於您看的那本書...小弟倒是很好奇.... :p SMP 主要的優點就是多工能力，上面已經有網友提到一個最簡單的例子了，當有一個 process 在等 I/O 動作時，不需要浪費時間在這個 thread 上，另一顆 CPU 可以執行另一個 process，這個時候 就不能看成是 1+1 =2 了，如果應用程式支援 multi-thread 時，SMP 就能發揮大於單一一顆 CPU 的速度了，但是由於一些條件上的限制，像是 Intel 的 SMP 是兩顆 CPU share 一個 host bus，所以可能會卡在 host bus 的頻寬上，而 K7 採用的 EV6 bus 是 peer to peer 的，兩顆 CPU 有各自的 bus，但是通往 memory 的 bus 只有一條，所以可能會卡在 memory bus 上，P4 的 HT 由於兩個 logical cpu 要同時存取一個 L2，會可能因為 L2 不夠大而影響效能，而 K8 目前看來是 SMP 平台最暴力的，每顆 CPU 除了有自己的 bus 外，也各自擁有 memory bus，幾乎是有幾顆 CPU 就有幾顆的效能，目前的一些測試看起來也似乎如此，但是，說實在的，一般使用者真的用不到.....XD 如果加上 OS 的話就更複雜了，一般多執行緒 OS 就有 time sharing、優先權式、robin bird 之類的排程方法，加上 SMP 後就更複雜了，不過可以肯定的是 SMP 可以做的事比 single cpu 多，也比較能稱得上是多工；但是，除非自己有架站服務別人或是想自己弄個 file server 的人外，一般玩遊戲、看影片或打報告是用不上的.... :p |
太感動了!還沒被罵到一頭狗血!!!
其實我也是很看好K8，不過，就目前，公司打死也不可能讓我花這個錢。一來RedHat都還沒推出『正式版』的OS來對應K8雙CPU的規格。一來在MP時，已經失望過一次...... 屁話一下：在x86的系統，不論哪種OS，雙CPU的系統很難會有到1.7倍，1.3倍就很了不起了，小弟很想了解一下是哪套OS與軟體會有這種神效..........這是硬體架構的問題，不是OS的錯。目前I/O的工作『好像』已不是CPU的事了，印像中『應該』是北橋的工作（好像有錯，請別理我）。 有關那本書，前兩年flag有翻過它的中文本，是與管理Win2000有關的（那本書並不是在教讀者如何去使用win2k，而是在講一些win2k的觀念、與實際運用時的建議）。 我試過在MP 2.2G上與XP 2.4G上用Tmpgenc轉半小時的DV，XP 2.4G從頭到尾CPU的loading大概都在100%，MP則在70%左右。看起來MP就是比單CPU『好看』。不過，如果我告訴你，架MP的成本是2.4G的兩倍以上（光是Power就無敵貴，更別說MP所要求的RAM規格...），結果完成的時間...幾乎一樣......真不曉得該說什麼.......不過，兩者的晶片完全不同，MP用的是AMD的，XP是VIA的..... 給準備要玩雙CPU，又要使用創巨音效卡的網友參考一下：目前SMP架構配合MS OS，很常聽到搭配創巨音效卡會有問題..........不過，我之前的BX組合倒是不會。 |
回覆: 回覆: 回覆: 請問雙CPU系統，執行一般的應用程式...有差別嗎？
引用:
winme我記得不支援雙CPU |
引用:
[恕刪...] 看了這樣的感言，實在很想要買一台Dual CPU的機器。 小弟平時在 compile 程式，一邊寫文件時，電腦就會 delay 的滿嚴重的，雖然現在使用了 raid 0 之後比較減緩，但仍然感覺到開視窗變慢等... |
Linux 並沒有所謂的 distro 支援才有，硬體支援是由核心決定的，據小弟所知，2.4 後期版本的 kernel 已經支援 K8 了，而測試中 2.6 將做更進一步的 optimization，有能力自己 make kernel 的話就不需要等所謂 distro 廠商發表了，自己抓 source 來 compile... :p
至於能不能發揮所有 cpu 的能力，除了硬體限制外，也要看 OS 多工能力，以及軟體是否支援 multi-thread，更深入的話就是是否軟體執行時的平行度高不高，以此看來 SMP 系統最適合的是當成 server 機、繪圖工作站之類的用途，用來轉檔可能幫助有限，不過可以確定的是較不容易造成系統因為壓縮程式佔據 cpu time 造成影音不同步之類的情形，比較容易看出 SMP 的幫助的就是平行編譯，可以比單顆同等級 CPU 縮短不少時間。 另外，SMP 的效能跟是否是 x86 沒有太大的直接關係，而是硬體架構及軟體方面的 OS 排程與應用程式是否能有效利用 SMP 有關。 |
回覆: 回覆: 回覆: 回覆: 請問雙CPU系統，執行一般的應用程式...有差別嗎？
引用:
win9x 核心是不支援 SMP 的，而且也認不到第二顆 cpu，所以跟單顆 cpu 是一模一樣的。 |
給準備要玩雙CPU，又要使用創巨音效卡的網友參考一下：目前SMP架構配合MS OS，很常聽到搭配創巨音效卡會有問題..........不過，我之前的BX組合倒是不會。
------------------------------------------------------------------ 好像是指使用AMD晶片組的雙MP CPU跟serverwork 的雙XEON系統.... 創新未來的AUDIGY系列,會搶PCI匯流排的頻寬,造成PCI匯流排上的傳輸出現問題, 這應該是硬體上面的相容衝突,之前知道,全球使用某些設備的影音製作雙AMD MP CPU的工作站上面加上Creative音效卡後,發生執行錯誤的問題,死傷無數,怨聲載道.. 倒是使用intel 的還沒聽說有災情傳出.... |
這是小弟超級簡陋的測試數據，用 AMD 舊的 MP 跑的，第一個是單純跑 PCMark04，第二個數據是一邊跑大家最常用的「超級拍」，然後跑 PCMark04。
CPU 3381.0 3028.0 Memory 1467.0 1242.0 Graphics 228.0 225.0 不過沒有測試單顆 CPU 同時跑，因為這樣要拆 CPU，而那是一件工程，還要花時間，加上難拆的風扇... 所以就偷懶了~ :nonono: CPU 掉最多的部分是 File Encryption 與 DivX Video Compression，Image Processing、WMV Video Compression、Audio Conversion 也會受到影響。這邊應該是因為原本程式可利用多處理器，因為部分 CPU 資源已經被「超級拍」超級拍，所以效能就被拉下來了。 而記憶體也會被影響，應該是「超級拍」要把算完的資料放回記憶體，當然，也要由記憶體讀資料來算。 所以可以發現，多 CPU 是有多工有好處，不過要注意瓶頸的部分。例如說，如果說您常用的程式都要持續讀寫硬碟，那就算多工，程式之間還是再擠那個較窄的硬碟傳輸。反之推到其他獨一性的資源，應該結果會類似。:) 這個測試非常非常非常不嚴謹，所以如果有錯請包涵。如果正好手邊有多處理器的人也可以測測，提供大家更詳細的數據~ :like: |
恕刪..........................
CPU的工作站上面加上Creative音效卡後,發生執行錯誤的問題,死傷無數,怨聲載道.. 倒是使用intel 的還沒聽說有災情傳出.... [/B][/QUOTE] __________________________________________________________ 南橋該不會是萬惡的686b吧:shock: |
| 所有的時間均為GMT +8。 現在的時間是01:03 AM. |
vBulletin Version 3.0.1
powered_by_vbulletin 2025。