"It's not about perfect. It's about effort. And when you implement that effort into your life… every single day, that's where transformation happens. That's how change occurs. Keep going, remember why you started."
純亂入： 用車比喻 CPU 也是我很愛的方式啊～XD 不過這通常是在說明速度的方面，效能通常會綜合速度與應用兩者來談...不過原發問人的問題我覺得應該要改成問「效率」，在某部分可以看做是貨櫃車在比容量的（這關係到記憶體了）。
簡單來說，如果開著 x86 去買馬鈴薯，基本容量 2G 個，早期一次載回的馬鈴薯並不少；但是馬鈴薯會越來越大顆，每次載回來的顆數會漸漸變少（遊戲、軟體在執行所需的記憶體都越來越大），除非駕駛永遠安於只載一顆或幾顆基本量（一次執行很多軟體，或只安於每次只執行一個軟體），不然整體效率會隨時間而逐漸變低了。
如果能開 x64 貨櫃車去，載的就變多了，基本就可以超過 4G 個，能夠容忍的馬鈴薯就更大顆了，同時又能載更多！只是看車頭後面要拖多大的貨櫃（當然也有上限），在馬鈴薯尚未沒大到 x64 車頭無法負擔之前，「效率」在貨櫃夠大的情況下，當然會比 x86 好。
如果 x86 or x64 都只是用同樣的小貨櫃，或是自己要的馬鈴薯並不多，效果當然不明顯，至於 x86 or x64 的貨櫃車頭誰比較快，還是要看引擎設計（幾管線、計算量輸出入的瓶頸）與 CC 數的（CPU的時脈），當然，有安裝 F1 引擎的 x86 貨櫃車跟安裝 1600CC 引擎的 x64 貨櫃車，跑得快不一定有效率、跑得慢不一定載不多。
如果你是在 Vista 底下開著 Office 2007 做簡報、FIREFOX 開個 70 幾個 TAB 看一堆 FLASH、跑個 VMware 掛 Linux 抓驢子+BT+APM、後面視窗偷偷開個魔獸上交易頻道等等，林林總總要花個4G記憶體以上的，x64 CPU + x64 作業系統當然會「更快」，因為同時執行很多軟體，讓你覺得整體效率變高了；如果只是開瀏覽器、聊聊天、打打楓之谷，換了 x64 也不會覺得快的。
19 則留言:
被點名了, 可是.....
他X的別說x64, 我自己的電腦都還沒有一台超越1GHz的障礙了! 要我怎麼回答這種問效能的問題啊?
就我的了解, x64跟之前16->32一樣只是延伸資料的動態範圍而已, 光這點不要期待原本用爬的會變成用飛的, 頂多是GPR多一點好辦事而已
只不過玩遊戲超過29.97fps是會飛嗎? 轉多媒體檔是有多常轉啊? 了不起比痴漢水球做愛的次數多一點而已吧! 把這些拿掉之後, "效能"到底跟吳伯雄的"自我感覺良好"比起來有多什麼意義嗎?
之前我跟別人聊過了, 過去CPU的進步本來就是大家都瘋了, 就像SR-71, XB-70, MiG-25那些只要衝高速的時代的產物一樣. 耗油不說, 連轉彎都有困難, 可是卻叫做"科技結晶".
不, 先進的CPU還打進消費市場, 這就更瘋了! 這相當於每個人都買台SR-71來開, 開去幹什麼? 開去買馬鈴薯啊! 大家還跟左鄰右舍吵, 嗆說我家的SR-71買馬鈴薯比你家的快, 可是真的有忙到一秒幾十萬上下非得開SR-71買馬鈴薯嗎? 沒有啊! 絕大部分的時間SR-71是停在地面然後人坐在旁邊啃馬鈴薯, 何苦呢?
現在終於有點覺醒了, 到了後P4時代Pentium-M又重出江湖, 至少大家知道穿音速性能比較重要, 改成開F-15買馬鈴薯了
最近大家還有一個重大發現, 就是原來開螺旋槳飛機一樣可以買到好吃的馬鈴薯, 這就是Atom, C7, Nano這些東西了
ㄜ...我就是那位提出大哉問的同學...
其實當初寄信給水球主要是因為小弟在PCADV雜誌十二月份的達人之路X86處理器發展史專欄中195-196頁看到水球對處理器執行X64＆X86的效能做了一些解說，還有196頁的比較表而產生的疑問。
就如Asuma大大所說，玩遊戲超過29.97fps也不會飛（我個人也認為一些人提倡FPS遊戲要達到60fps才順暢的只是心理因素或是I/O的延遲），轉檔也不會一天到晚都在轉，或是某些benchmark也不會天天跑。
坊間許多測試也顯示，在X86或X64這兩種環境下玩遊戲、轉檔、解壓縮，等...似乎都沒有太大的差距！
而小弟本來的認知也是認為X86->X64只是延伸資料的動態範圍。但是看到水球的解說後，既有的想法就被混亂了。
小弟不是要去計較一些不實際的效能數據，或是要去探討開什麼東西去買馬鈴薯會更快...看到那個32/64位元指令效能比較表，就挑起了小弟的好奇心，這指令效能的差距目前真的會影響到一般的End user嗎？
總之，小弟的疑問是...
既然32/64位元指令效能在同一顆處理器會有差距，那現在我們看到坊間測試出來的數據會沒有太大差別是因為，測試環境的X86或X64都只是指該測試環境的OS是X86或X64，而使用的軟體本身卻是用X86相容模式在執行嗎？
又為什麼同一顆處理器在執行32/64位元指令的效能會有如此差距呢？
先謝謝各位博學多聞的大大了...
我想還是差在GPR多好辦事的問題, 最主要還是要看x64的compiler有沒有好好利用這些多出來的GPR, 減少無謂的洗進洗出
不過目前Intel x64 CPU都有使用新增GPR時，decoder端輸出率下滑，或fusion機制受限的問題，不清楚Nehalem到底解決多少。
唯一可以確定的是，如果你要裝大容量記憶體，64位元是絕對有用的。XD
單就指令來看，比較複雜的64位元整數邏輯運算，像乘除法之類的，速度比32位元來得慢，其實並不令人意外吧？但歷史的教訓證明，應用程式絕大多數會用到的指令，也多半是簡單的指令。
我覺得應該要先「澄清」一個觀念，就是 64 bits 倒底有什麼用。
基本上，64 bits（不管是哪種 CPU）的最重要用途，和可以進行 64 bits 運算無關。很多 32 bits CPU 都可以進行 64 bits 運算。更不用說，大部份的程式都用不到 64 bits 運算。事實上，絕大多數的 64 bits 系統，它最常用的資料型態，仍是 32 bits 整數。64 bits 指令集的重點，是可以進行 64 bits 定址。也就是說，可以使用超過 4GB 記憶體。
當然，理論上，只是想要使用超過 4GB 記憶體，也是有很多招式，例如 x86 的 PAE。但是，就算使用 PAE，同一個 process 仍只能使用 4GB 的記憶體空間。當然，OS 可以提供一些類似 EMS 的 windowing 機制，但是歷史告訴我們那很不好用，效率也差。
但是，64 bits 模式也有缺點，就是指標變大了。這對於需要做 point chasing 或大量指標處理的程式來說，也是不利的。這就是為什麼很多 64 bits 系統上，如果是不需要用到 4GB 以上記憶體的程式，還是很常會以 32 bits 模式去 compile、去跑的原因。
現在來考慮 x86 的 64 bits 模式。x64 最重要的特色，就是它的暫存器多出 8 個，聽起來算是不錯。不過，為了使用這多出來的暫存器，指令需要多一個 byte 的 prefix。這會增加指令的平均長度，是一個不利的點。
對 x86 來說，因為 x86 的 GPRs 本來就很少，所以 x86 CPU 在設計上就很重視高速的 L1 cache。因此，增加 GPRs 的數目，對一般的 x86 CPU 來說，能帶來的幫助，其實可能沒有想像中的那麼高（指相對於 RISC CPU 來說）。
當然，有些程式會很常用到 64 bits 運算，這時 64 bits 的運算指令可能就不錯。不過，像這樣的程式並不是很多。
總而言之，目前如果要裝 64 bits 的 OS，唯一的理由就是要使用超過 4GB 的記憶體。以目前的記憶體價格來說，我想很快每台新電腦都會有 4GB 記憶體了 XD
純亂入：
用車比喻 CPU 也是我很愛的方式啊～XD 不過這通常是在說明速度的方面，效能通常會綜合速度與應用兩者來談...不過原發問人的問題我覺得應該要改成問「效率」，在某部分可以看做是貨櫃車在比容量的（這關係到記憶體了）。
簡單來說，如果開著 x86 去買馬鈴薯，基本容量 2G 個，早期一次載回的馬鈴薯並不少；但是馬鈴薯會越來越大顆，每次載回來的顆數會漸漸變少（遊戲、軟體在執行所需的記憶體都越來越大），除非駕駛永遠安於只載一顆或幾顆基本量（一次執行很多軟體，或只安於每次只執行一個軟體），不然整體效率會隨時間而逐漸變低了。
如果能開 x64 貨櫃車去，載的就變多了，基本就可以超過 4G 個，能夠容忍的馬鈴薯就更大顆了，同時又能載更多！只是看車頭後面要拖多大的貨櫃（當然也有上限），在馬鈴薯尚未沒大到 x64 車頭無法負擔之前，「效率」在貨櫃夠大的情況下，當然會比 x86 好。
如果 x86 or x64 都只是用同樣的小貨櫃，或是自己要的馬鈴薯並不多，效果當然不明顯，至於 x86 or x64 的貨櫃車頭誰比較快，還是要看引擎設計（幾管線、計算量輸出入的瓶頸）與 CC 數的（CPU的時脈），當然，有安裝 F1 引擎的 x86 貨櫃車跟安裝 1600CC 引擎的 x64 貨櫃車，跑得快不一定有效率、跑得慢不一定載不多。
如果你是在 Vista 底下開著 Office 2007 做簡報、FIREFOX 開個 70 幾個 TAB 看一堆 FLASH、跑個 VMware 掛 Linux 抓驢子+BT+APM、後面視窗偷偷開個魔獸上交易頻道等等，林林總總要花個4G記憶體以上的，x64 CPU + x64 作業系統當然會「更快」，因為同時執行很多軟體，讓你覺得整體效率變高了；如果只是開瀏覽器、聊聊天、打打楓之谷，換了 x64 也不會覺得快的。
這問題可以拆成幾個層次：
1. 哪些應用程式會經常用到64位元長整數？
2. 64位元的記憶體定址效率？
3. 64位元的指令執行效率？
4. 64位元執行檔的額外體積與記憶體頻寬壓力？
最後，CPU執行64位元程式時，實作加速機制會出現哪些限制與瓶頸？
不過如果要我選擇，假如應用程式相容性都沒問題，我個人蠻偏好使用x64的OS，呵呵。
原問題:
小的想請問一個愚拙的問題，就單純個人電腦使用起來，
如果使用intel core2系列處理器，在X86＆X64兩種環境下處理的效能會差很多嗎？
例如：玩遊戲、轉檔、解壓縮，等...
路人回答:
既然問題已經限制在"單純個人電腦使用上",
"使用intel core2系列處理器","在X86＆X64兩種環境下",表示變數只有OS,所以所有軟體和硬體都要相同,這樣子來看軟體不能用64bit版(因為這樣不能比較),記憶體也只能用4GB(同理這樣不能比較)
這樣子來看,32位元效能應該會勝過64位元
應用上會有三種情境：
32 bits AP on 32 bits OS
32 bits AP on 64 bits OS (WOW64)
64 bits AP on 64 bits OS
這還可分成記憶體容量「超過4GB」與否兩種狀況，更不用講x64 Long Mode還有native與相容兩種模式，分頁表不同page size的效應就更懶得提了。
我不知道原作者到底在問哪一種，不過「32 bits vs 64 bits的效率差距」本來就是牽連甚廣的大哉問，原始問題這樣看下來...似乎只是有人看到Core 2部份比較複雜的64位元指令跑的比32位元慢一些，就懷疑64位元的效率會有問題，其實我覺得這是沒有必要的，真正最該擔心的是Pentium 4，而不是Core 2和K8。
反正當每台電腦都裝個幾GB後，64 bits就是不得不為的選擇。
> 反正當每台電腦都裝個幾GB後，64 bits就是不得不為的選擇。
其實這倒也不一定, 其實大可把Virtual machine跟OS完美結合, 給每個32bit程式都開個VM然後獨占4G"實體"的記憶體, 連page table都可以省了, 這樣爽不爽啊?
VMware沒事嗆MS就是在嗆這個, 這是未來的VM&OS的趨勢, 而且MS其實也動手下去玩了
其實OS本身就可以歸類為一種VM了, 只不過VM的觀念比OS晚問世, 所以大家比較沒有這樣的直覺罷了
從VM走向OS或是OS走向VM其實都是同一個必然的方向
就算是Hypervisor，也還是省不掉page table啊！像Intel EPT和AMD NPT就是為了「欺騙」每個VM都有獨立的page table，避免shadow page消耗太多的CPU cycle。
Asuma提的作法應該是屬於Physicla/Logical Partition之類的方式，直接切割底層硬體資源，不過這和VMware就沒有太大的關聯了。
這一篇文章滿有意思，大家可以參考一下
Backward Compatibility ≠ Forward Scalability?
http://blogs.intel.com/research/2008/03/backward_compatibility_forward.php
用 x64 OS 看謎片不會比 x32 OS 下多快轉兩倍速, 我想你要問的是這個 (炸)
簡單回好了.
1.遊戲, 目前只看過 farcry 跟 crysis 這兩個有 port 64bit 的版本, 其它就沒再看到了. 現在已經有記憶體材質精細度開到最大 1G VRAM 會不夠用的怪物出現了, 往後會不會有更大, 大到非用 x64 OS 不可的我想機會很低很低, 就光講最需要記憶體的材質資料來說, 可以繞路走的寫法也多, 64bit OS 不是必要.
2.影音壓縮. 以目前看過的 codec kernel 來講根本沒有必需要上 x64 的必要..
3.檔案解壓縮, 我想你比較需要的是 RAMdisk 而非 x64 OS..
而且以上三樣程式主要執行範圍都不會很大, 就會有像 hotball 所說的不利情況, 即使是指標用很多仍可用 register file 硬吃下來好了, 還有 register file 被 OS 備份/回存的 overhead 在 (寫寫 SSE 的 code 就體會的到了..), 除非你是跑非常大的圖而且還要算圖, 64bit 直接索引才比較能發揮威力, 但是對於這個問題, 可以繞道走的走法又很多了...
所以你可以看的到, 有很多很多說支援 x64 的軟體都是 driver 層的東西是 x64 的, 但應用軟體卻還是 32bit 的. 也就是說, 如果只是為了要完全使用 4G 以上的記憶體而去跑 64bit OS, 以現在這個時間點來講真的很浪費.
而且題外話, 64bit coding 不好 tune performance, 有興趣可以來玩玩看.
to Asuma
在下不贊同您用SR-71、XB-70和Mig-25來比喻超過實際需求的CPU效能。
1.
先談SR-71，這種機型的用途，是在敵方領空拍攝敵方要地，取得重要情報，並以高空高速的飛行性能自保並順利完成任務。
其最大優勢為可持續以超過3馬赫的高速巡航1X00公里。
當時匿蹤技術未成熟，要完全避開敵方雷達偵測是不可能的。而一旦被雷達發現，偵察機逃開對方攔截機和飛彈的追擊，完成偵查任務和帶回所獲情資。
而最能保護偵察機免於飛彈毒手的，非高空-高速，即高能量(位能+動能)莫屬，此優勢使飛彈追擊偵察機時，需耗費不少能量先爬升至高空，才能以剩餘的動能追擊高速遠離的偵察機。
由於高空-高速巡航的性能，SR-71雖然多次穿越北極熊等敵方陣營的領空進行偵查，但都沒有被敵方擊落的紀錄。
因此，在下以為SR-71的高性能是為了美國進行秘密戰略偵查而生，並非不符需求的產物。
2.
XB-70的研發計畫，是基於老美戰略轟炸的需要。和偵察機相同，高空-高速是匿蹤之外，轟炸機自保的好方法。並非為高速而高速。
3.
Mig-25的定位是高空高速攔截機，假想敵是老美的高空高速偵察機和轟炸機。
研發目的是為了更有效的攔截老美的SR-71和可能出現的高空高速轟炸機。因為當時的防空飛彈和戰鬥機無法有效打擊前兩者，也是因應實際需求而生，並非所謂的為高速而高速。
我想Asuma的重點並不在於是那些飛機是否是為了高速而高速
而是在於
大多數的一般使用者並沒有必要每個人都裝一顆高速cpu(或說高效能cpu)
打個比方說就像是裝了9770只為了打打報告 上上網一樣可笑
沒錯，Asuma所提的重點是高性能CPU超過一般人的使用需要。
不過在下是對於Asuma大主張中，使用不當的類比，提出反對意見。
就此例來說，一般人用單核心Cpu打文書、開許多含flash的網頁，頂多是速度慢了些，讓使用者不爽
但在老美對北極熊進行的秘密戰略偵查中，偵察機需面對為數甚多，極速超過偵察機最高速的防空飛彈追擊，速度慢一些就有可能遭遭飛彈毒吻。另外，至少會有十幾架次的敵方戰鬥機試圖擊落偵察機，同樣的，偵察機如果慢到被戰鬥機或戰鬥機發射的飛彈追上，那也註定倍擊落。
換個說法，SR-71、XB-70和Mig-25的關係就像獵豹與蹬羚，蹬羚為逃過獵豹的獵殺，必須設法跑的更快，而獵豹為了捕到蹬羚，也必須跑的更快，於是此兩物種便為生存，進行著無止盡，一代又一代的速度競逐。
這些速度競逐都是因為生存競爭，因為弱肉強食，何來為高速而高速呢?
下個總結:
一般人不必用高性能CPU的情形是
Speed doesn't matter.
SR-71、XB-70和Mig-25為高速而生是因為
Speed does matter.
兩者相距甚遠，所以在下才認為Asuma用以上三機的性能、定位去類比'先進CPU'的說法有問題。
假設你身上永遠都有十塊錢
以前的十元只能買模型飛機拿在手上飛
現在的十元能買搖控飛機在天上飛
未來的十元能買真的飛行器載你飛
就算你平常走路買大番薯
今日十元就是要花在飛機上
那你會買模型飛機 還是??
張貼留言