假設處理器是64位的，不是很明顯以64位運行OS會在各個方面都更好嗎？

實際上不是，不是。在某些方面，運行64位操作系統 可能會降低Raspberry Pi的性能。

64位的優點：

使用64位處理器/操作系統的兩個主要好處是，該設備可以處理超過4 GB的RAM，並且可以自然地處理大於 2 ^ 32 的整數，而無需使用bignum庫。

在撰寫本文時，Raspberry Pi的RAM不超過4 GB（注意：截至2020年8月，RPi 4的RAM為2至8 GB）。在1 GB的RAM上，您已經完全失去了兩個主要好處中的第一個。至於第二個好處，實際上有多少百分比的人使用了足夠大的數字以使基金會支持整個第二個操作系統？照原樣，RPi可以通過軟件方法使用大量軟件，但是如果您要在那個領域保持一致，則無論如何都需要使用更好的硬件。

問題64位：

魔術沒有授予存儲更大數字的能力。而是，需要增加存儲對象的大小。在C（和C ++）中，這意味著將 int 更改為 int64_t 。這不是自動完成的，因此有關基礎的註釋不希望維護兩個分支。

此外，許多應用程序在64位模式下運行時（對於大多數用戶而言）根本沒有提供任何好處。請注意，大多數Web瀏覽器，MS Office以及大量其他流行軟件仍以32位的方式提供和維護。當然，您可以使用64位版本的MS Office，但很少使用。

如果編寫應用程序/操作系統以利用64位體系結構，則您的應用程序將使用更多的內存，僅因為變量和指針佔用了更多的空間。通常，對於要從特權中受益的機器來說，這是一個相對較小的折衷。在我們的例子中，我們的特權很少，而RAM卻很少。計算機，並不意味著該應用程序未以32位運行。 Windows通過具有兩個不同的安裝路徑（ C：\ Program Files 和 C：\ Program Files（x86））使這一點非常清楚。

那麼，基金會可能會提供64位支持嗎？：

我們回到了同一點，“有些人可能會看到好處，但大多數人不會。”您肯定會看到其他提供64位構建的項目，但是除非基金會獲得很多不當（imo）漏洞，否則它們可能不會也不應（imo）。創建和維護一個單獨的64位分支並不是一件容易的事，老實說，這似乎並不值得。

值得注意的是，ARM和Intel / AMD的情況有所不同。那是因為切換到x86_64還被用作更新嚴重老化的體系結構的機會，該體系結構由於只有8個通用寄存器而受到嚴重破壞，並且在64位模式下增加了一倍。因此，將Intel / AMD系統切換到64位模式還意味著啟用真正的功能，這些功能會在性能上產生重大差異。

ARM並沒有遇到這個問題（儘管AArch64添加了寄存器， 32位體系結構並沒有挨餓），因此，好處基本上是可直接尋址的內存和對本機大整數的支持-少了很多大事，而且可能被缺點（更多的內存用於所有功能）抵消了。 / p>

（由於這個原因，在為Intel / AMD Linux創建“ x32” abi方面已經做了一些工作，保留了CPU增強功能，但使用了32位指針）

我確定在Pi 3上已經有運行Debian Aarch64（ARMv8）的人了；對於許多人來說，肯定不會那麼難（請參閱此處，以獲取一些可能的線索） ^{1 sup>，儘管對於大多數用戶而言，}

但是，如果Raspbian和/或Foundation沒有提供64位版本，您將越來越多地看到擁有博客的人，等等，解釋瞭如何運行一個博客。

Pi 3現在有 Fedora aarch64版本。

^{1。 32位的 / opt / vc 東西會帶來一些麻煩，我不確定這是多麼可克服。曾經有x86-64的32位compat庫，但Aarch64 ...也許不是。 sup>}

在發布會的發布中，我看到它提到，一個問題是維護兩個單獨的代碼庫（32位和64位）需要付出的努力。 Adafruit PI3 Launch視頻還提到，遷移到64位處理器更多的是關於新芯片提供的時鐘速度提高，而不是使用64位模式。

要解決這樣一個斷言，即64位本機程序更大（用於數據和指針的更多內存），並且ARMv8上RAM小於4GB的64位與32位OS沒有明顯的好處，我希望提出了幾點。

在體系結構上，ARMv7（及之前）和ARMv8的處理方式存在一些顯著差異，這些差異使ARMv8的執行效率更高。其中一些來自更廣泛的內部數據路徑，一些來自特殊情況的消除，以及更深層次的渠道）。這些相同的更改使ARMv8更好地運行了ARMv7（32位）代碼。

本地64位應用程序確實使用64位指針，而“ size_t”是64位，因此使用那些指針的元素的確變大了。其餘數據將趨於保持相同大小。但是，這對於可執行映像的大小而言意義不大。

64位本機真正令人眼前一亮的地方（如果您不關心大整數和浮點數的話）具有更大的虛擬空間。地址空間：

• 操作系統可以將虛擬地址空間劃分為更多和更大的部分，從而可以更輕鬆地管理共享資源，在不同特權級別之間進行更簡化的上下文切換，等等。
• 如果啟用了交換功能，則可以運行更多和更大的進程，而超出了物理內存限制（實際上在32位中也是如此，但在64位中則較少）

無論操作系統當前是否在利用此優勢，隨著主流版本從32位移開，它將有所作為。

我認為移植到本地64位AArch64內核的最佳論據是可移植性：主流台式機已移至大多數64位處理器，並且我看到更多采用64位的軟件包，並將此類代碼移植回32位。位比從32位移植到64位更難。在用戶空間中，假設已經安裝了多體系結構庫，則能夠並排運行32位應用程序和64位應用程序，因此不需要將32位應用程序移植到64位應用程序物。 64位操作系統只會為您提供更多的軟件選擇。

我並不是說為Raspberry PI 3生成64位內核很容易-存在重大差異，需要在以下地方進行更改在較低級別，並非所有設備驅動程序都是64位乾淨的（尤其是ARM特定GPU的驅動程序）。 Raspberian可能仍將是32位操作系統，但我認為（從長遠來看）它是短視的。

單個引導媒體（例如SD卡）可以同時包含64位和64位操作系統。操作系統和32位版本，以及輔助引導軟件（u-boot，arm-boot和其他引導軟件）可以確定要加載哪個。更難的部分是用戶空間-文件系統必須是多體系結構，即使在32位系統上，如果64位的東西將是無用的。我將用一個腳本或實用程序解決這個問題，該腳本或實用程序可以在初次啟動後運行，以刪除僅32位系統上不需要的庫和程序可執行文件。

即使您的內存不足1GB，也可以使用64位尋址。

它允許您對大型文件進行內存映射，因此您有了一個指針並讓操作系統透明地進行I / O。進行I / O的另一種方式。需要對大型文件執行64位尋址。

另一個我認為有用的示例是允許進程具有2GB以上的地址空間，使用交換空間。我最近在具有大量存儲空間和損壞的文件系統的32位NAS上遇到問題。即使打開了緩存選項，fsck進程也會用完內存。添加交換空間無法解決問題，那裡的32位地址空間是硬限制，因此無法在如此大的損壞下運行fsck具有32位二進製文件的文件系統。如果使用64位二進製文件和一些交換空間，它將可以運行。

現有的答案很好地解決了64位拱門的問題，但是我看不到升級的許多優點。因此，這是我最近發現的兩個：

• 當PHP處理Unix時間戳時，32位arch中的整數大小設置了日期上限，因此它們不能超過在2038年的某一天。我希望這是所有處理時間戳的語言的問題。 （值得慶幸的是，大多數不使用Unix時間戳的日期處理子系統，例如PHP的DateTime，都是經過專門設計的，即使在較舊的CPU上也不受此問題的限制。）

• Mongo僅限於數據庫該拱門的大小不到2G，並且很快將棄用32位版本。從手冊：

  從MongoDB 3.2開始，不贊成使用32位二進製文件，並且在以後的版本中將不可用。

  儘管32 Linux和Windows存在位構建，它們不適合生產部署。 32位版本也不支持WiredTiger存儲引擎。

我的想法：儘管我不確切知道ARM處理器如何尋址內存，但是我可以從我以前在（SPARC / Alpha / i386 / AMD64 / X86_64）上編程過的多個CPU體系結構中告訴您這一點：通過“真正的”虛擬地址指針進行內存和尋址，轉移到64位並非易事。儘管memcpy可以完成預期的工作，但您需要考慮的是，數據以64位這樣存儲（向後存儲）：

  HGFEDCBAHGFEDCBAHGFEDCBA  

還用32位，看起來像這樣：

  ABCDABCDABCD  

因此，當您在RAM中存儲一個jpeg時，您可以讀取其32位標頭字節，或進行邊緣檢測，而不會出現任何線性問題，例如通過逐字節向前移動。但在64位體系結構中，此更改為：

32位：

  for（i = 0; i< img_length / 4; i ++） {address = shm_start + i;對於（c = 0; c< 4; c ++）{字節=（（*地址>> c）& 15）}}  

64位：

  for（i =-; i< img_length / 8; i ++）{address = shm_start + i; for（c = 7; c> = 0; c--）{字節=（（*地址>> c）& 15）}}