Raspbian移至64位模式

在此页面中，RPi3官方公告指出：

您需要从我们的下载页面上获得最近的NOOBS或Raspbian映像。在启动时，我们使用的是与其他Raspberry Pi设备相同的32位Raspbian用户区。在接下来的几个月中，我们将调查转向64位模式是否有价值。

我的问题是，因为该处理器是64位的，是不是很明显的是在运行64位操作系统将在各方面都好？我想念什么？

假设处理器是64位的，那么以64位运行OS在各个方面是否会更好会明显吗？

不，实际上不是。在某些方面，运行64位操作系统可能会使Raspberry Pi的性能下降。

64位的好处：

使用64位处理器/操作系统的两个主要好处是，该设备可以处理4 GB以上的RAM，并且本地处理的整数大于2^32不需要bignum库的整数。

Raspberry Pi的RAM不超过4 GB。在1 GB的RAM上，您已经完全失去了两个主要好处中的第一个。至于第二个好处，实际上有多少百分比的人使用了足够大的数字以使基金会能够支持整个第二个操作系统？照原样，RPi可以通过软件方法使用大量软件，但是如果您要在那个领域保持一致，则无论如何都需要使用更好的硬件。

问题与64位：

魔术并不授予存储更大数量数字的能力。而是，需要增加存储对象的大小。在C（和C ++）中，这意味着将更int改为int64_t。这不会自动完成，因此有关基础的注释不希望维护两个分支。

此外，在64位模式下运行时，许多应用程序（对于大多数用户）根本无法提供任何好处。请注意，大多数Web浏览器，MS Office和大量其他流行软件仍以32位的方式提供和维护。当然，您可以使用64位版本的MS Office，但很少使用。

如果编写应用程序/操作系统以利用64位体系结构，则您的应用程序将使用更多的内存，仅仅是因为变量和指针占用了更多的空间。通常，对于要从特权中受益的机器来说，这是一个相对较小的折衷。在我们的情况下，我们的特权很少，而RAM却很少。

还要注意：

仅仅因为您在64位计算机上运行，​​并不意味着该应用程序未以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位体系结构并没有饿死），所以好处基本上是直接寻址的内存和本地大整数支持-少了很多交易，并且可能被不利因素抵消（更多的内存用于所有操作）。

（此外，由于这个原因，在为Intel / AMD Linux创建“ x32” abi方面做了一些工作，保留了CPU增强功能，但使用了32位指针。）

我确定在Pi 3上已经有运行Debian Aarch64（ARMv8）的人了。它肯定不会那么难了很多人（在这里看到了一些端倪有关可能的工作）¹虽然对于大多数用户来说可能是有点夸张。

但是，如果Raspbian和/或Foundation没有提供64位版本，您将越来越多地看到博客等人，向他们说明如何运行它并仍然获得所需的东西。

Pi 3 现在有一个Fedora aarch64版本。

^{1. 32位的/opt/vc东西会有一些麻烦，我不确定那是多么可克服。曾经有x86-64的32位compat库，但Aarch64 ...也许不是。}

作为发布宣传的一部分，我看到它提到的一个问题是维护两个单独的代码库（32位和64位）需要付出的努力。Adafruit PI3 Launch视频还提到，迁移到64位处理器更多地是关于新芯片提供的时钟速度增加，而不是使用64位模式。

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

它允许您对大型文件进行内存映射，因此您有了一个指针，并让OS透明地执行I / O。这是执行I / O的另一种方式。您需要64位寻址才能对大型文件执行此操作。

我认为它有用的另一个示例是，使用交换空间允许进程拥有超过2GB的地址空间。我最近在具有大量存储空间和损坏的文件系统的32位NAS上遇到问题。即使打开了缓存选项，fsck进程也会用完内存。添加交换空间不能解决问题，那里的32位地址空间是硬限制。因此，没有办法在带有32位二进制文​​件的损坏较大的文件系统上运行fsck。如果使用64位二进制文​​件和一些交换空间，它将可以运行。

解决了这样的断言：64位本机程序更大（用于数据和指针的更多内存），并且对于RAMv小于4GB的ARMv8上的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位和32位版本的OS，而辅助引导软件（u-boot，arm-boot和其他引导软件）可以确定要加载哪个。更难的部分是用户空间-文件系统必须是多体系结构，即使在32位系统上，如果64位的东西将无用。我将使用脚本或实用程序来解决此问题，该脚本或实用程序可在初次启动后运行，以删除仅32位系统上不需要的库和程序可执行文件。

现有的答案很好地解决了64位拱门的问题，但是我没有看到许多明显的升级优势。所以，这是我最近发现的两个：

• 当PHP处理Unix时间戳时，32位拱形中的整数大小会设置日期上限，以使日期不能超过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位这样存储（向后存储）：

HGFEDCBA
HGFEDCBA
HGFEDCBA

但是在32位中，它看起来像这样：

ABCD
ABCD
ABCD

因此，当您在RAM中存储一个jpeg时，在32位中，您可以读取其标头字节或进行边缘检测，而不会出现任何线性问题，例如通过逐字节向前移动。但是在64位架构中，这会发生变化：

32位：

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64位：

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}