題 32位與64位系統


32位和64位系統有什麼區別?

如果您同時使用它們,您遇到了什麼樣的明顯差異?

在某些情況下,在64位系統上使用32位程序會有問題嗎?


219
2017-10-17 11:14


起源


這裡存在許多混淆,而在網絡上,在物理尋址(訪問ram)PEA影響這一點,主板影響這一點,以及邏輯尋址(每個進程的虛擬內存)之間。在32位操作系統上,虛擬內存限制為4GB減去內核預留的內存。它獨立於RAM,你可以擁有0.1MB或8GB的RAM,你可以擁有4GB的虛擬內存(但有一些是由內核保留的)。 PEA可以用來擁有更多的RAM,但不是一個完美的答案,因為內核無法訪問它。 - ctrl-alt-delor


答案:


注意:這些答案適用於標準的基於x86的PC CPU(Intel和AMD)和Windows(通常為最終用戶配置)。其他32位或64位芯片,其他操作系統和其他操作系統配置可以有不同的權衡。

從技術角度來看,64位操作系統為您提供:

  • 允許單個進程分別處理超過4 GB的RAM(實際上,大多數但不是所有32位操作系統還將總可用系統RAM限制為小於4 GB,而不僅僅是每個應用程序的最大值)。

  • 所有指針都需要8個字節而不是4個字節。對RAM使用的影響是最小的(因為你不太可能有一個充滿千兆字節指針的應用程序),但在最糟糕的理論情況下,這可以使CPU緩存能夠容納1/2的指針(使得它實際上是1/2的大小)。對於大多數應用程序來說,這不是一個大問題。

  • 64位模式下還有許多通用CPU寄存器。寄存器是整個系統中最快的內存。在32位模式下只有8個,在64位模式下只有16個通用寄存器。在我寫的科學計算應用程序中,通過在64位模式下重新編譯,我已經看到了高達30%的性能提升(我的應用程序可以真正使用額外的寄存器)。

  • 大多數32位操作系統實際上只允許單個應用程序使用2 GB的RAM,即使安裝了4 GB也是如此。這是因為另外2 GB的地址空間被保留用於在應用程序之間,與OS共享數據以及與驅動程序通信。 Windows和Linux將允許您將這種權衡調整為3 GB用於應用程序和1 GB共享,但這可能會導致一些不期望更改的應用程序出現問題。我也猜測它可能會削弱具有1 GB RAM的顯卡(但我不確定)。 64位操作系統可以使單個32位應用程序更接近完整的4 GB。

從用戶的角度來看:

  • 與32位操作系統上的32位版本的應用程序相比,64位操作系統中的64位應用程序的應用程序速度通常更快,但大多數用戶不會看到此加速。普通用戶的大多數應用程序並沒有真正利用額外的寄存器,或者通過填充緩存的更大指針來平衡好處。

  • 如果您有任何內存佔用應用程序(如照片編輯器,視頻處理,科學計算等),如果您已經(或可以購買)超過3 GB的RAM,並且您可以獲得該應用程序的64位版本,選擇很簡單:使用64位操作系統。

  • 某些硬件沒有64位驅動程序。在進行切換之前,請檢查您的主板,所有插卡和所有USB設備。請注意,在Windows Vista的早期,驅動程序存在很多問題。這些天通常情況更好。

  • 如果你一次運行這麼多的應用程序,你的RAM用完了(通常你可以告訴這個,因為你的計算機開始變得非常慢,你聽到硬盤驅動器崩潰),那麼你需要一個64位操作系統(和足夠的RAM)。

  • 您可以在64位Windows中運行32位應用程序(但不是驅動程序),沒有任何問題。我在64位Windows中測得32位應用程序的最慢速度大約是5%(這意味著如果在32位Windows中花費60秒做一些事情,最多花費60 * 1.05 = 65秒64位Windows中相同的32位應用程序)。

什麼是32位與64位  意味著:

在x86系統上,32位與64位  指的是指針的大小。就這樣。

  • 它不是指C的大小 int 類型。這是由特定的編譯器實現決定的,大多數流行的編譯器選擇32位 int 在64位系統上。

  • 它不是  指的是普通非指針寄存器的大小。但是,64位運算寄存器的使用恰好要求應用程序和OS也以64位指針模式運行。

  • 它不是  指的是物理地址總線的大小。例如,具有64位寬緩存行和最大512GiB存儲器的系統在其地址總線中僅需要33位(即 log2(512*1024**3) - log2(64) = 33)。

  • 它沒有涉及物理數據總線的大小:這與製造成本(CPU插槽中的引腳數)和高速緩存行大小更相關。


262
2017-10-17 13:11



很好的答案。特別是因為您注意到實際上沒有4GB RAM限制,但是進程內存使用限制。僅供參考,我認為你應該看看這個鏈接: unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN - Breakthrough
它們是不能在64位窗口上運行的應用程序:16位應用程序/使用32位或無符號內核模式驅動程序的應用程序。對於像我這樣的軟件癮者來說,這是很多...... - fluxtendu
@flextendu,鑑於這些舊程序的性能要求,您幾乎可以肯定在虛擬機中運行它們。有了VMware播放器,Virtual PC和Virtual Box,如果您擁有32位Windows許可證,則沒有理由不試用其中一個。如果您不想弄亂它,它們也可能在“Windows XP Mode”下工作。 - Mark Booth
BTW,32位應用程序不會使用超過2 GiB的RAM,除非在其清單中啟用了特定標誌。資源: blogs.technet.com/b/markrussinovich/archive/2008/11/17/... - Hello71
是的,我確定Hello71已經找到了一些非常重要的東西,這裡沒有涉及:大多數32位應用程序永遠不會直接利用額外的RAM。我覺得這值得一提,不是嗎? - Django Reinhardt


基本上你可以做更大規模的事情:

  1. 每個OS的RAM: 操作系統的x86 RAM限制為4GB(大部分時間)
  2. 每個進程的RAM: 進程(總是)x86上的RAM限制為4GB。如果您認為這不重要,請嘗試運行龐大的MSSQL數據庫密集型應用程序。如果你有它並且運行得更好,它將使用> 4GB本身。
  3. 地址: 地址是64位而不是32位,允許您擁有使用更多內存的“更大”程序。
  4. 程序可用的句柄: 您可以創建更多文件句柄,進程,...在Windows x64上的示例,您可以為每個進程創建> 2000個線程,但在x86上接近幾百個。
  5. 提供更廣泛的課程: 從x64,您可以運行x86和x64程序。 (示例窗口:wow64,windows64仿真上的windows32)
  6. 仿真選項: 從x64,您可以運行x86和x64 VM。
  7. 快點: 在64位CPU上,某些計算速度更快
  8. 劃分多個系統資源: 當您想要運行至少一個分割系統資源的VM時,很多RAM內存非常重要。
  9. 獨家課程: 一些新程序僅支持x64。 Exchange 2007示例。
  10. 未來過時的x86?: 隨著時間的推移,將使用越來越多的64位,並且將不會使用越來越多的x86。因此供應商將只支持64位以上。

兩種類型的64位體系結構是x64和IA64體系結構。但到目前為止,x64是最受歡迎的。

x64可以運行x86命令以及x64命令。 IA64也運行x86命令,但它不執行SSE擴展。 Itanium上有專門用於運行x86指令的硬件;它是一個模擬器,但在硬件中。

正如@Phil所說,你可以深入了解一下 它是如何工作的


107
2017-09-25 12:19



嗯。 IA64運行x86命令。但它不會進行SSE擴展。 Itanium上有專門用於運行x86指令的硬件;它是一個模擬器,但在硬件中。 - tzot
幾年前,Raymond Chen發表了關於2000線程“限制”的文章,它或多或少是一個都市傳奇: blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx - bk1e
為Arstechnica提供了解釋。 - Avihu Turzion
RAM限制為4GB並不完全正確(這是對家庭用戶Windows系統的人為限制),檢查 PAE。使用最新的硬件,Linux PAE內核(默認情況下用於32位)可以滿足4GB以上的要求。同樣適用於FreeBSD和NetBSD。 - Izzy
由於“地址”(第3個節點),32位系統不能使用超過4GB(第1個節點)。因為最高的32位數是4.294.967.296(= 4GB)。所以你的第一和第三個懲罰是相同的。你可以刪除第3個punct。 :) - Jet


人們現在註意到的最大影響是32位PC只能處理最大4GB的內存。當您取下操作系統分配給其他用途的內存時,您的PC可能只顯示大約3.25GB的可用內存。移到64位,此限制消失。

如果你做了認真的發展,那麼這可能非常重要。嘗試運行多個虛擬機,很快就會耗盡內存。服務器更可能需要額外的內存,因此您會發現服務器上的64位使用率遠遠高於台式機。摩爾定律確保我們將在機器上擁有更多內存,因此在某些時候桌面也將切換到64位作為標準。

有關處理器差異的更詳細說明,請查看此優秀文章 ArsTechnica


46
2017-09-25 12:16



32位平台和4GB限制有點用詞不當,主要是操作系統架構選擇/設計限制。實際上,32位的4GB實際上是處理VA空間的限制。物理地址在Intel 32位CPU上支持36位 - Tall Jeff
你提出了一個肯定是正確的觀點。但PC用戶在現實世界中的影響是,機器不會使用他們支付的全部4GB。我爸爸有這個問題,但仍然感到困惑的是,他付的4GB無法充分利用。
感謝您的觀點,但只是試圖推動修復不在處理器或64位的概念,這只是一個略微改進的OS設計的問題。例如,這可以在Windows的企業版本上解決,甚至可以在32位版本中解決。它允許64GB的RAM。 - Tall Jeff
從技術上講,限制不會消失。它進一步發展到在未來十年左右的任何時間在機器上安裝那麼多RAM是不切實際/不可能的。
看我的評論 PAE 上圖:整個系統的4GB限制不適用 - 但僅適用於單個進程(沒有進程可以訪問4GB及以上 - 但整個系統,即所有進程一起,可以啟用PAE)。因此,除非有一個應用程序能夠訪問4GB及以上(例如視頻編輯器/轉換器與大視頻文件) 和 安裝8GB +,無論使用32位還是64位都不會有太大的差別。 - Izzy


沒有什麼是免費的:雖然是64位應用程序 能夠 訪問比32位應用程序更多的內存,缺點是他們 需要 更多的記憶。所有這些指針過去需要4個字節,現在需要8個。例如,當為64位架構構建時,Emacs中的默認要求是內存增加60%。這種額外的佔用空間會損害內存層次結構的每個級別的性能:更大的可執行文件需要更長的時間從磁盤加載,更大的工作集會導致更多的分頁,更大的對象意味著更少適合處理器緩存。如果你考慮一個具有16K L1緩存的CPU,32位應用程序可以在它未命中之前使用4096個指針並進入L2緩存,但是只有2048個指針後,64位應用程序必須達到L2緩存。

在x64上,這可以通過更多寄存器等其他體系結構改進來緩解,但在PowerPC上,如果您的應用程序無法使用> 4G,它可能在“ppc”上比“ppc64”運行得更快。即使在英特爾上,有些工作負載在x86上運行得更快,而在x64上運行速度比x86快5%。


31
2017-10-13 10:45



這個答案表明PowerPC64不如x86-64好。事實上,powerpc64沒有改善powerpc,因為powerpc沒有被破壞。 - ctrl-alt-delor
Linux現在有一個x32 ABI,具有x86-64(更多寄存器,重新設計的ABI)的所有速度優勢,但具有32位指針。 +1表示64位模式的好處不是來自實際的寬度增加,而是來自丟棄大量承載架構的行李的機會。 64位寄存器對某些應用程序有價值,但通常不需要64位指針空間。 - Peter Cordes


64位操作系統可以使用更多RAM。在實踐中,這就是它。 64位Vista / 7使用更高級的安全功能,將重要組件放置在RAM中,但這並不是真正“明顯”的。

來自ChrisInEdmonton:

ix86上的32位操作系統   PAE系統最多可以解決64個問題   GB的RAM。 64位操作系統   在x86-64上最多可以訪問256 TB   虛擬地址空間,雖然這可能   在隨後的處理器中被提升   到16 EB。注意一些操作   系統限制了地址空間   而且,大多數主板都會   有額外的限制。


19
2017-10-17 11:24



對於OS,32位與64位ONLY僅指指針的大小(第一段正確討論的內容)。 -1:某些操作系統選擇將默認整數大小鎖定為指針大小,但Windows和Linux都不這樣做。整數數學精度不變。沒有廣泛使用的OS改變浮點精度(第二段聲稱的)。 “float”或“single”是32位,“double”是64位,無論操作系統是使用32位還是64位指針。 - Mr Fooz
啊,我顯然是錯了,謝謝你清理:) - Phoshi
沒問題。 -1 - > +1 - Mr Fooz
可能值得編輯您的答案,說明可以訪問多少RAM。帶有PAE的ix86系統上的32位操作系統可以處理高達64 GB的RAM。 x86-64上的64位操作系統可以訪問高達256 TB的虛擬地址空間,儘管這可能會在後續處理器中提升,最多可達16 EB。請注意,某些操作系統會進一步限制地址空間,並且大多數主板都會有其他限制。 - ChrisInEdmonton
我希望保持簡單,就像數字一樣 大多 現在已經高到不相關了,但現在堅持下去也不會有什麼壞處。 - Phoshi


我不確定如果不寫一篇完整的文章就會回答你所有的問題(總是谷歌......),但你不需要為64bit設計不同的應用程序。我想要提到的是你必須注意指針大小不再與整數相同的大小。而且,對於某些類型的數據的內置假設,您有一大堆潛在的問題,這些數據長度為四個字節,可能不再適用。

這可能會使應用程序中出現各種問題 - 從保存/加載文件,迭代數據,數據對齊,一直到數據的按位操作。如果你有一個現有的代碼庫,你正試圖移植,或者兩者兼而有之,那麼很可能你會有很多小問題需要解決。

我認為這是一個實施問題,而不是設計問題。即我認為“設計”說,無論單詞大小,照片編輯包都是一樣的。我們編寫的代碼可以編譯為32位和64位版本,並且兩者之間的設計肯定沒有區別 - 它是相同的代碼庫。

64位的基本“大問題”是你可以訪問比32位更大的內存地址空間。這意味著你可以真正地將超過4Gb的內存放入你的計算機中並實際上讓它有所作為。

我相信其他答案會比我更詳細和有益。

在檢測差異方面,然後以編程方式檢查指針的大小(例如sizeof(void *))。 4的答案意味著它的32位,8意味著你在64位環境中運行。


14
2017-09-25 12:29



如果你編寫的程序隨便假設某些指針類型與某些整數類型的大小相同,那麼你就可以了。這已經很久了。 - David Thornley
@David:你說得對。不幸的是,那裡有大量代碼可以做到這一點。


32位進程的虛擬地址空間為4 GB;對於某些應用來說,這可能太少了。 64位應用程序具有幾乎無限的地址空間(當然它是有限的,但您很可能不會達到此限制)。

在OSX上還有其他優點。見 下面的文章,為什麼讓內核在64位地址空間中運行(無論你的應用程序運行64或32)或讓你的應用程序在64位地址空間運行(內核仍然是32位)導致更好的性能。總結一下:如果任何一個是64位(內核或應用程序,或兩者當然),只要你從內核切換到使用空間並返回(這將加速),就不必刷新TLB(“轉換後備緩衝區”) RAM訪問)。

使用“long long int”變量(64位變量,如uint64_t)時,您也可以獲得性能提升。 32位CPU可以添加/分頻/減去/乘兩個64位值,但不能在單個硬件操作中。相反,它需要將此操作拆分為兩個(或更多)32位操作。因此,一個可以使用64位數運行很多的應用程序將具有能夠直接在硬件中進行64位數學運算的速度增益。

最後但並非最不重要的是,x86-64架構比傳統的x86架構提供更多的寄存器。使用寄存器比使用RAM快得多,CPU佔用的寄存器越多,將寄存器值交換到RAM並返回寄存器所需的頻率就越低。

要確定您的CPU是否可以在64位模式下運行,您可以查看各種sysctl變量。例如。打開終端並輸入

sysctl machdep.cpu.extfeatures

如果列出EM64T,則根據x86-64標準,您的CPU支持64位地址空間。你也可以尋找

sysctl hw.optional.x86_64

如果它表示1(真/啟用),則CPU支持x86-64位模式,如果它表示0(假/禁用),則不支持。如果根本找不到該設置,則認為它是假的。

注意:您還可以從本機C應用程序中獲取sysctl變量,而無需使用命令行工具。看到

man 3 sysctl

10
2017-09-25 12:34



錯誤:“machdep.cpu.extfeatures”是一個未知密鑰
我想它不會被稱為EM64T,如果你不幸不能擁有英特爾。


請注意,地址空間可用於超過(實際)內存。人們還可以映射大型文件,這可以提高更奇怪的訪問模式的性能,因為更強大和更有效的塊級VM級別緩存啟動。由於堆管理器較少,因此在64位上分配大型內存塊也更安全可能會遇到地址空間碎片,不允許它分配大塊。

在這個線程中所說的一些事情(比如#個寄存器的加倍)只適用於x86-> x86_64,而不是64位。就像在x86_64下保證有SSE2,686操作碼以及廉價的PIC方法一樣。這些功能嚴格來說不是64位,而是關於削減遺留和修復已知的x86限制

此外,人們常常指出將寄存器加倍作為加速的原因,而更有可能是默認的SSE2使用可以解決這個問題(加速memcpy和類似的功能)。如果為x86啟用相同的集,則差異會更小。 (*) (***)

還要記住,通常會涉及初始懲罰,因為平均數據結構將因為指針的大小更大而增加。這也有緩存效果,但更重要的是,平均memcpy()(或任何與您的語言相同的內存複製)需要更長時間。這僅僅是幾個百分點的量級,但上面提到的加速也是如此。

通常,64位體系結構上的對齊開銷也更大(以前32位記錄通常只是32位和64位值的混合),甚至更多地炸毀了結構。

總的來說,我的簡單測試表明,如果驅動程序和運行時庫完全適應,它們將大致相互抵消,對於普通應用程序沒有顯著的速度差異。然而,一些應用程序可以突然變得更快(例如,當依賴於AES時)或更慢(關鍵數據結構不斷移動/掃描/走動並且包含許多指針)。雖然測試是在Windows上進行的,因此PIC優化沒有進行基準測試。

請注意,大多數JIT-VM語言(Java,.NET)平均(內部)使用的指針明顯多於例如C ++。可能他們的記憶使用比平均程序增加更多,但我不敢直接將其等同於減緩效果(因為這些是非常複雜和時髦的野獸,並且通常難以預測而無需測量)

(*)一個鮮為人知的事實是SSE寄存器的數量在64位模式下也加倍

(**)Dobbs博士幾年前有一篇很好的文章。


9
2018-05-01 21:19





除了大多數人在這裡提到的明顯的記憶問題之外,我認為值得研究一下Knuth(以及其他人)最近一直在談論的“廣義詞計算”的概念。通過位操作可以獲得很多效率,64位字的逐位運算比32位字更進一步。簡而言之,您可以在寄存器中執行更多操作而無需記憶,從性能角度來看,這是一個非常巨大的勝利。

看看第4卷,前分冊1A,我正在談論一些很酷的技巧。


8
2017-09-25 12:36