Raspbian会迁移到64位吗？

#1 楼

假设处理器是64位的，不是很明显在64位上运行操作系统会在各个方面都更好吗？

不，实际上不是。在某些方面，运行64位操作系统可能会降低Raspberry Pi的性能。
64位的优点：
使用64位处理器/操作系统的两个主要好处是该设备可以处理更多操作。大于4 GB的RAM，并且本地处理大于2^32的整数而无需bignum库。
在编写Raspberry Pi时，其RAM不超过4 GB（注意：截至8月。 2020年，RPi 4具有2至8 GB的RAM）。在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位分支并不是一件容易的事，老实说，这似乎并不值得。

#2 楼

值得注意的是，ARM和Intel / AMD的情况有所不同。这是因为切换到x86_64还被用作更新老化严重的体系结构的机会，该体系结构基本上只有8个通用寄存器，并且在64位模式下增加了一倍，因此受到严重损害。因此，将Intel / AMD系统切换到64位模式还意味着启用真正的功能，这些功能会在性能上产生重大差异。 32位体系结构并没有挨饿），因此好处基本上是可直接寻址的内存和本机大整数支持-少了很多大事，而且可能被缺点（更多的内存用于所有功能）抵消了。

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

#3 楼

我确定在Pi 3上已经有运行Debian Aarch64（ARMv8）的人了。虽然对于大多数用户来说可能有点麻烦，但对于许多人来说当然并不难（参见此处的一些线索可能有用）1。该基金会没有提供64位版本，您会越来越多地看到博客等人，向他们说明如何运行博客并仍然获得所需的东西。


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


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

#4 楼

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

#5 楼

解决了以下主张：64位本机程序更大（用于数据和指针的更多内存），并且对于ARMv8上具有少于4GB RAM的64位和32位OS没有明显的好处，我想提出一些要点。

在体系结构上，ARMv7（及更高版本）和ARMv8的处理方式存在一些显着差异，这些差异使ARMv8的执行效率更高。其中一些来自更广泛的内部数据路径，一些来自特殊情况的消除，以及更深层次的渠道）。这些相同的更改使ARMv8更好地运行了ARMv7（32位）代码。

本地64位应用程序确实使用64位指针，而'size_t'是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位版本以及辅助引导软件（u-boot，arm-boot和其他引导软件）可以确定要加载哪个。更难的部分是用户空间-文件系统必须是多体系结构，即使在32位系统上，如果64位的东西将是无用的。我将用一个脚本或实用程序解决这个问题，该脚本或实用程序可以在初次启动后运行，以删除仅32位系统上不需要的库和程序可执行文件。

#6 楼

即使您没有超过1GB的内存，也可以使用64位寻址。透明的I / O。进行I / O的另一种方法。
您需要64位寻址才能在大型文件上执行此操作。使用交换空间的地址空间超过2GB。我最近在具有大量存储空间和损坏的文件系统的32位NAS上遇到问题。即使打开了高速缓存选项，fsck进程也会用完内存。
添加交换空间不能解决问题，32位地址空间是其中的硬限制。在具有32位二进制文​​件的损坏较大的文件系统上运行fsck的方法。使用64位二进制文​​件和一些交换空间，它将可以运行。

#7 楼

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


当PHP处理Unix时间戳时，32位arch中的整数大小设置了日期上限，因此它们不能超过在2038年的某个特定日子。我希望这对于处理时间戳的所有语言都是一个问题。 （值得庆幸的是，大多数不使用Unix时间戳的日期处理子系统，例如PHP的DateTime，都是经过专门设计的，即使在较旧的CPU上也不受此问题的限制）。该拱门的大小，很快将弃用32位版本。从手册中：


从MongoDB 3.2开始，不赞成使用32位二进制文​​件，并且在将来的版本中将不可用。对于Linux和Windows，它们不适用于生产部署。 32位版本也不支持WiredTiger存储引擎。

#8 楼

我的想法是：
虽然我不完全知道ARM处理器如何寻址内存，但我可以从以前在（SPARC / Alpha / i386 / AMD64 / X86_64）上编程过的多个CPU体系结构中告诉您： />使用共享内存并通过其“真实”虚拟地址指针进行寻址时，迁移到64位并非易事。尽管memcpy可以完成预期的工作，但您需要考虑的是，在64位数据中，存储的数据是这样的（向后位）：

HGFEDCBA
HGFEDCBA
HGFEDCBA

在32看起来像这样的位：

ABCD
ABCD
ABCD

因此，当您将jpeg存储在RAM中时，以32位的形式，您可以读取其标头字节或进行边缘检测，而无需任何操作以线性方式出现问题*通过逐字节前进来表示。但是在64位体系结构中会发生以下变化：

32位： /> 64bit：

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