64位軟件和32位軟件最大的區別是：64位的軟件可以同時操作大於4GB的內存（註意這裏的內存指的是地址空間，而不是物理內存）。
比如現在有壹個10GB的數據庫需要進行排序。64位的軟件可以動態的分配壹個10GB的空間把整個數據庫“放進”內存然後使用任意經典排序算法，而32位的軟件在動態分配時就會崩潰。所以32位軟件的程序員只能使用復雜的算法顯式的分塊讀入，局部排序，寫回數據庫，然後重復。這樣不僅程序復雜難寫，程序員交換內存和文件的算法效率可能也不如操作系統自動處理來的高效。
另壹方面，64位軟件巨大的內存空間也可能加速物理內存的消耗，增加尋址的開銷，因此未必總是能夠提高性能。當然最終系統的效率還是取決於物理內存的大小，64位只是解決了地址空間的瓶頸。32位CPU和64位CPU的區別？32位、64位CPU在指令集合、操作數位數、寄存器名稱和個數等都不相同。
比如壹條mov
eax，1指令，可能在32位CPU上對應的機器指令是0x1201；在64位機器上就是0x123401。程序對於機器CPU而言，僅僅是壹系列順序躺在內存中的01代碼而已，而硬件上直接運行的是操作系統，所以妳馬上得出結論：32位的CPU只能運行32位的操作系統，64位同理。
這麽設計的確在理論上沒什麽不妥，實際上intel
IA
64架構的處理器就是這樣的，64位的CPU上只能運行64位的操作系統（操作系統本身也是軟件，也是壹系列指令序列）。但這樣問題就來了：我需要升級硬件來提速，難道買了CPU以後，要把上層的操作系統和應用軟件通通換掉？
這種軟硬件不兼容帶來的問題就是，沒有多少客戶會去購買這種沒法兼容32位原有軟件環境的CPU。所以，後來intel和amd都推出了兼容32位原有軟件環境的CPU（intel
的x86&64和amd的amd64）。也就是說，現在主流的64位CPU，上面可以運行32位和64位的操作系統。編譯器與程序位數編譯器也是壹個應用軟件，64位機器上的64位編譯器編譯出來的也就是64位的應用軟件。
但是有沒有例外呢？那第壹個64位的操作系統是怎麽來的？我們都知道現在操作系統壹般是用C語言實現的，然後像普通程序壹樣經過編譯器編譯成可執行文件，難道64位的操作系統不是用64位的編譯器編譯出來的？很顯然，妳的第壹個64位的操作系統，需要用“64位”的編譯器來生成，但妳的64位的編譯器運行在什麽操作系統上呢？
當然，我肯定運行在64位的操作系統之上，那妳64位的操作系統從哪裏來呢？死循環狀態中。所以，必然有壹種編譯器，本身是32位的軟件，但能夠將程序編譯成64位的可執行文件，也只有這種情況下，編譯器本身位數和編譯出來程序的位數才不壹致。
操作系統位數和軟件位數的關系這裏，我們首先要弄清壹個軟件是如何被運行的，我們以C文件為例，討論我們經典的hello
word程序：#include<stdio.h>int main(){printf("hello
world")}壹個源程序首先被預處理，尋找頭文件，將頭文件包括進來，裏面有printf的申明。然後被編譯成目標文件，註意目標文件已經是二進制文件了，裏面的符號表中有main、printf等，但是很顯然，這個prinf不是我們自己寫的，我們僅僅有它的申明而已。
此時如果我們查看目標文件，就會發現目標文件中的printf函數是extern標記，表示這是壹個外部符號，並不是我們定義的。顯然，這時目標文件是沒法運行的，因為裏面有未知符號沒有解析。目標文件經過鏈接，形成可執行目標文件。因為操作系統提供了已經編譯好的動態鏈接庫，所以此時我們僅僅經過鏈接，神奇的hello就能執行了。這樣，妳是不是沒有感覺到妳的軟件有32位和64位的區別？妳管它叫128位都沒問題。
但是，上述過過程有幾個非常重要的地方：
1）動態鏈接庫
2）系統API首先，妳32位的操作系統上壹般是沒有64位的庫文件，如果妳的應用程序源代碼中引用了只有64位的動態庫中才有的函數，很顯然妳鏈接的時候就會出問題。
另外，我們很多程序肯定用到了read和write等C語言庫函數，而庫函數的實現是依賴於系統API的。如果妳工作在windows上，程序大多數是以exe形式發布的，妳得到的程序是目標文件以後的結果，本身是帶有位數的；如果妳工作在linux上，本身大部分軟件包rpm等也是已經編譯好的，就是說，它們本身就是具有“位數”的。
如果妳得到的是源碼，那麽基本上妳的應用程序還沒有“位數”的概念，妳用多少位的編譯器去編譯它，它就是多少位的應用程序。我們這裏討論多少位的程序，都是針對已經編譯到目標文件以後的狀態。所以32位和64位軟件的並存是CPU、系統、編譯綜合決定的，而這些都是因為時代的需要。
對於Windows系統而言，64位的系統上往往有32位的庫和其他必要的信息，基本上能兼容32位的程序。以上是個人的壹些經驗和總結，希望可以幫助到大家，如果有不同意見和建議，歡迎評論區留言討論。