我知道 64 位比 32 位的優勢，但除了兼容性之外，32 位應用程式比 64 位應用程式有什么優勢可以使 32 位應用程式更快或更高效？
uj5u.com熱心網友回復：
簡而言之，沒有。更準確地說，理論上某些處理器可能是這種情況，但我不知道。
我想到的唯一另一個區別是 32 位指令通常更小（至少由于沒有 REX 前綴），因此您可以通過這種方式節省一些空間，但它可能不會超過x64。考慮到 x64 獨有的指令也往往具有更高的影響，即一次處理更多資料，x64 中的代碼甚至可能變得更緊湊。而且，出于同樣的原因，x32 通常較慢。所以不，除了兼容性之外，x32 與 x64 相比沒有任何真正的優勢。
uj5u.com熱心網友回復：
有一個很大的優勢：32 位應用程式使用的記憶體要少得多（正是因為指標更小）。并非所有東西都是指標，例如字串和數字不會改變它們的大小，因此有效差異不是 2x。我碰巧特別了解 JavaScript 引擎，對于相同的作業負載，64 位版本通常比相同引擎的 32 位版本多使用大約 50% 的記憶體。
V8 最近通過在其 64 位版本中實作“指標壓縮”來解決這個問題。理論上，任何 C/C 應用程式都可以做同樣的事情，但這是一項巨大的工程作業。
也就是說，這通常不是不遷移到 64 位的理由，因為其他好處（更多暫存器、更多地址空間）通常超過了這個缺點。但這確實意味著，如果您的目標是記憶體少于 4GiB 的設備/機器，如果記憶體消耗是一個問題，您可能希望堅持使用 32 位構建。
（根據我的經驗，性能是一個混合包：更小的代碼和更小的資料意味著在 32 位上更好的快取利用率；在 64 位上擁有更多和更寬暫存器的 OTOH 可以在那里保存指令。在極少數極端情況下，64 位應用程式可以同時處理兩倍的資料；大多數情況下，差異只會在 1-5% 的范圍內，并且可以朝任一方向發展：有時32 位構建確實比 64 位快一點-bit build；這實際上取決于應用程式在做什么。）
uj5u.com熱心網友回復：
對于 Windows 應用程式，32 位被視為“最便攜”（更易于分發），盡管這已不再是一個問題。
對于像 Ruby 這樣的記憶體豬，在我看來它使用了 1/2 的 RAM，因此您可以在 RAM 有限的機器上運行更多應用程式。更不用說“所有應用程式”使用更少的記憶體（內核等）
它的運行速度也更快，因為它遍歷所有記憶體進行垃圾收集，更適合快取，需要遍歷的整體 RAM 更少，查找指標等。同時，64 位不太可能發現 false當 GC 尋找指標時是積極的，所以在那里 64 位的勝利很小。
如果你真的很勇敢，你可以嘗試混合 x32 ABI（32 位指標，64 位暫存器）https://unix.stackexchange.com/questions/121424/linux-and-x32-abi-how-to-使用旨在獲得兩全其美的效果。我真的不確定為什么它不被認為是更受歡迎的選擇，這對我來說似乎是一個不錯的勝利，權衡是你不能擁有超過 2GB 的 RAM。我的猜測是大多數人并沒有處于 RAM 非常受限的環境中，或者直接使用“32 位內核”（得到很好的支持）的勝利還不夠激勵？從本質上講，大多數盒子都有大量 RAM，所以它不是優先事項？
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/351988.html
上一篇：使用numpy優化橫縱鄰接的計算