badcat寫到:
而 Linux 或 Unix 利害的地方就在將多個 CPU 在作業系統中仍當「『一個』極強的『虛擬』 CPU」(請注意，我強調的是一個！)，CPU 的資源統籌分配就交給 Linux 或 Unix 作業系統去模擬及調控。(若說明不對，還請 Linux 或 Unix 高高手指正！)
Linux 或 Unix 底下的軟體只看見「一個極強的虛擬 CPU」，至於怎麼分配，是作業系統的問題，所以軟體「根本」不需考慮「多核心的最佳化程式碼」，只要 CPU 數量一多，程式自然會提升效能。(程式根本不知道有「多個 CPU」的事情！)
這樣「軟體」階層就能避開 Windows 作業系統中「軟體」對「單/雙/多核心」程式碼「最佳化」的問題，「軟體」不需特意為「多核心程式碼的最佳化會影響執行效能」去改寫程式而傷腦筋，畢竟那是 Linux 或 Unix 作業系統階層的問題。
「2顆/2=1 虛擬」跟「512顆/512=1 虛擬」，在 Linix 或 Unix 中對程式而言，都是當成一顆「虛擬」CPU，但效能在 Linix 或 Unix 中就會差很多，但 Linux 或 Unix「程式軟體」階層是不必重寫的。(是作業系統在傷腦筋嘛！)

badcat寫到:
嗯！存疑是好事！不知道的事，小弟也不敢講死！

的確，Linux 或 Unix 如何協調多核 CPU 及多工之間的關係，不是小弟「小小的腦袋」可以理解的，就我所知的說明也不敢保證一定準確，說不定也有如 crazydark 兄所說的問題存在。
一個是為了解決跨平台及多核心資源分配而犧牲了部份效能！
一個是為了效能而犧牲了跨平台。

小弟所說的是為了能解決：每增加新的 CPU 架構，就要考慮重寫一次新的程式的困擾！ (程式設計師的因擾。)

個人認為多核 CPU 這個相關硬體的部份，應該交由「作業系統」階層來應付，而不要由「程式軟體」階層的程式設計師來處理。
第一. 太直接處理硬體 (缺乏彈性，硬體一變就要改程式)
第二. 不是每個程式設計師都能遵循多核心的最佳化標準來設計，很可能各自為政！
最後就是一堆 CPU 最佳化程式把多核心的 CPU 資源搞的一團糟！

所以小弟認為此問題最好能在硬體就解決，譬如內建多核心的晶片，到外部匯流排時，作業系統看到的就認為是一個 CPU 核心而已。(不過易缺乏彈性，比如說有很多個「多核晶片」串連 * n個時怎麼辦？)

所以從「作業系統」層面來解決，至少減少「軟體程式」層面要解決 CPU 硬體的問題，那程式在面對單/雙/多核時，都不用改寫程式，才不會每新增新的 CPU 硬體變動，「每套」軟體的最佳化都要改寫，才會有明顯效能改進的窘境。(這是理想啦！請別罵我啦！嗚！嗚！...)

P.S. 好像離題了？對不起！對不起！...

chaeung寫到:
個人獨斷的偏見：

無論單核雙核多核, 單工多工, 個人用和主機用根本沒有可比性.

1.32bit和64bit的差別僅在於定址最大範圍, 也就是說定址範圍愈大, CPU一次指令可處理的資料極限也就愈大, 理論上速度有差, 實際上還要看情形(OS+AP的配合度).
2.Windows這類GUI系統通常是個人使用, 有大量資源使用在GUI上, 本來速度就慢, 而且最主要是給人操作用的, 人的操作(閱讀)速度才是重點, 其實在圖形介面的後台也是以TEXT模式跑的; 而且, 快個幾分鐘或幾十分鐘應該只是個有參考價值的效能指標, 假設PC壽命3年不關機運作, 26280小時中像轉檔編碼這種密集運算能佔幾小時? 省下來的時間對個人而非公司而言有多少意義? 單人多工, 再怎麼多工也要等人, 除非人一直坐在電腦前從頭盯著螢幕看到尾, 否則程式跑完等人的這一等就把絕大部份節省下來的時間浪費掉了.
3.Unix/Unix-like等的TEXT模式介面系統雖然簡陋, 卻將資源完全用在實際運算上, 在相同硬體下先天就勝過GUI系統一大截, 所以比較正規或是有重要功能的主機幾乎都不會用Windows, , 本來就不是給人用... 呃... 給人長時間坐在電腦前面操作用, 所以也不用等人, 只要系統不crash, 就會不停運轉下去.
4.Unix/Unix-like最完美的結合典範是Mac OS X (FreeBSD+Mac GUI).

言歸正傳...

轉檔工作=從HDD讀取->送到RAM->CPU編碼->送到RAM->寫入HDD, 非3D就不提GPU了.
瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", ATA-100/133和SATA-150/300都完全沒有意義, 不少RAID Card甚至還要受PCI Bus速度的限制, 只要HDD來不及寫入資料(有些系統還可以寫入資料後再verify一遍更慢), CPU/RAM都要停下來等待, 此時N核N位元N THz的CPU和N TB的RAM都沒用(RAM Disk除外), 如果同一時間還有其它程式要對HDD進行讀寫, HDD速度立刻腰斬再腰斬(磁頭移動耗時).

所以, 結論是,
1.規劃好動作, 不要讓多個程式同時對同一顆HDD進行讀寫(免成本).
2.轉檔編碼等大動作要快, 錢花在CPU/RAM上不如花在HDD上(如RAID 0或Multiplier).
3.如果預算夠, 市面有DDR2 2GB一條的RAM, 插滿4槽8GB, 在XP64下足夠開RAM Disk了, 技嘉的i-RAM也可以, 而RAM Disk一開... 本篇就沒什麼好繼續的了.

以上

chaeung寫到:
個人獨斷的偏見：

無論單核雙核多核, 單工多工, 個人用和主機用根本沒有可比性.

1.32bit和64bit的差別僅在於定址最大範圍, 也就是說定址範圍愈大, CPU一次指令可處理的資料極限也就愈大, 理論上速度有差, 實際上還要看情形(OS+AP的配合度).
2.Windows這類GUI系統通常是個人使用, 有大量資源使用在GUI上, 本來速度就慢, 而且最主要是給人操作用的, 人的操作(閱讀)速度才是重點, 其實在圖形介面的後台也是以TEXT模式跑的; 而且, 快個幾分鐘或幾十分鐘應該只是個有參考價值的效能指標, 假設PC壽命3年不關機運作, 26280小時中像轉檔編碼這種密集運算能佔幾小時? 省下來的時間對個人而非公司而言有多少意義? 單人多工, 再怎麼多工也要等人, 除非人一直坐在電腦前從頭盯著螢幕看到尾, 否則程式跑完等人的這一等就把絕大部份節省下來的時間浪費掉了.
3.Unix/Unix-like等的TEXT模式介面系統雖然簡陋, 卻將資源完全用在實際運算上, 在相同硬體下先天就勝過GUI系統一大截, 所以比較正規或是有重要功能的主機幾乎都不會用Windows, , 本來就不是給人用... 呃... 給人長時間坐在電腦前面操作用, 所以也不用等人, 只要系統不crash, 就會不停運轉下去.
4.Unix/Unix-like最完美的結合典範是Mac OS X (FreeBSD+Mac GUI).

言歸正傳...

轉檔工作=從HDD讀取->送到RAM->CPU編碼->送到RAM->寫入HDD, 非3D就不提GPU了.
瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", ATA-100/133和SATA-150/300都完全沒有意義, 不少RAID Card甚至還要受PCI Bus速度的限制, 只要HDD來不及寫入資料(有些系統還可以寫入資料後再verify一遍更慢), CPU/RAM都要停下來等待, 此時N核N位元N THz的CPU和N TB的RAM都沒用(RAM Disk除外), 如果同一時間還有其它程式要對HDD進行讀寫, HDD速度立刻腰斬再腰斬(磁頭移動耗時).

所以, 結論是,
1.規劃好動作, 不要讓多個程式同時對同一顆HDD進行讀寫(免成本).
2.轉檔編碼等大動作要快, 錢花在CPU/RAM上不如花在HDD上(如RAID 0或Multiplier).
3.如果預算夠, 市面有DDR2 2GB一條的RAM, 插滿4槽8GB, 在XP64下足夠開RAM Disk了, 技嘉的i-RAM也可以, 而RAM Disk一開... 本篇就沒什麼好繼續的了.

以上