在8GB RAM树莓派4上检查树莓派OS 64位的运行情况

原文链接:Checking Out Raspberry Pi OS 64-Bit on Raspberry Pi 4 8GB RAM 由Jean-Luc Aufranc撰写。

去年6月带有 8GB RAM树莓派4是与树莓派 OS 64 位的beta版一起推出的。在当时安装新版本的用户其实很少,很多人使用的还是 32 位版本的 Raspberry Pi OS(以前称之为 Raspbian),因为那个时候 64 位的版本还存在很多错误且缺少一些功能。但因为我想了解最新版本的进度,所以我就安装了raspios_arm64-2020- 05-28/2020-05-27-raspios-buster-arm64.zip,并且我在启动板子的时候也没有遇到什么问题。我们一起来看看当时的情况:

树莓派操作系统 64 位系统信息

在桌面环境中我通过设置向导配置了语言、时间、网络等,并且为了确保操作系统是更新后的,我还查看了一些信息:


我确实有一个带有 8GB 内存的树莓派 4 Model B Rev 1.4版(修订版:d03114),该镜像带有 64 位的 Linux 内核:


我确实也得到了一个 64 位的根系统文件(rootfs)。


一切看起来也都很正常。

已知的问题

在开始评测之前,我们先了解一下已知问题:

1)在免费开源跨平台的多媒体播放器 VLC 上 或 Chromium 中是没有硬件视频加速的
2) libraspberrypi0、libraspberrypi-dev 和 libraspberrypi-doc 已从 /opt/vc/* 移到了 /usr/* 中(目的是使其更标准)。针对这些库构建的任何代码都需要更改以引用更标准的位置(/usr/lib/ 而不是 /opt/vc/lib)
3) 由于第(2)个问题,许多需要 libGLESv2.so libEGL 等的包都需要重新编译
4) raspberrypi-bootloader 和 raspberrypi-kernel 包含无用的非 64 位二进制文件,并且缺少为最小化文件删除和安装到 /boot 之间的延迟所做的工作
5) 没有为 AArch64 构建的 Wolfram Mathematica
6) Minecraft 填充层需要重建以应对问题(2)
7) VLC 需要重新编译(不可用)
8) VNC 服务器尚未为 64 位重新编译

树莓派操作系统 64 位基准测试

大多数基准测试对 RAM 容量的要求不高(非涉及交换情况除外),但我仍然安装了 sbc-bench,用来与使用 Raspbian Buster 32 位镜像树莓派4(1GB RAM)获得的结果进行了比较:


SBC Bench的结果:


32位和64位树莓派OS的对比
32位和64位树莓派OS的对比

请注意,我使用的是KKSB 铝制外壳,因此散热不是问题。我们可以在下表中看到测试结果的比较(所有的数据都是越高越好)。

 Raspberry Pi 4 @ 1.5 GHz
Raspbian 32 位 – 1GB RAM
Raspberry Pi 4 @ 1.5 GHz
RPI OS 64 位测试版 – 8GB RAM
memcpy (MB/s)2,662.52,503.6
memset (MB/s)3,436.93,359.5
OpenSSL AES-256-CBC 16K64,951.64k30,157.48k
7-zip5,397*5,082.33

* 7-zip测试结果主要是针对树莓派 4 +散热器(不是 KKSB)的早期测试,因为在 KKSB 评测中,7-zip 内存不足且未完成。

正如我们所看到的,64 位的操作系统在所有四个结果中都比较慢。memset/memcpy 的差异也很小,7-zip的数据大约落后了 6%,而 AES-256 hash的测试数据则落后了高达 50+%。其实,我对后者并不感到惊讶,因为从2019年1月以来,就有人树莓派上的 Debian OS 32位与64位 sbc-bench 脚本中的 AES-256-SBC 16KB测试进行了比较,并且获得了类似的结果。但不知什么原因 SHA1SUM(SHA1 hash函数)在 64 位操作系统上要快很多。

树莓派OS 64位上进行功能测试和多任务处理

现在让我们尝试运行常规程序来找出潜在的错误或限制,同时看看总内存使用量什么时侯会超过 4GB RAM,超过之后再切换到 8GB RAM,这样的切换会比较值得。

在树莓派4 上运行8GB 64位树莓派OS
在树莓派4 上运行8GB 64位树莓派OS

我使用 htop(已使用 + 缓冲区 + 缓存)来监控总内存的使用情况。首先是运行带有多个选项卡、YouTube 和 Facebook 游戏(Candy Crush Saga)的 Chromium 浏览器,加载 VLC、Thunderbird、带有 .odt 文件的 LibreOffice,以及带有照片的 GIMP。

我还运行了 glxgears -info 用来确认图形加速是正在工作的(从Candy Crush Saga来看这一点也已经很明显了)。


我还在 VLC 中试着播放了 720p 和 1080p 的视频(H.264/H.265)。你们也可以查看下面的视频了解所有的步骤。

相关视频链接,点击此处可查看

总而言之,树莓派OS 64 位现在的运行已经相当稳定了。Chromium 的使用也没有什么大问题,除了 YouTube 的播放还有一些问题。因为现阶段还缺乏一些硬件视频解码,播放1080p 视频的时候CPU占用率会过高,而 Candy Crush Saga (HTML5) 确实需要很长时间才能加载完成,但是一旦加载完成之后游戏播放就会很流畅了。我可以使用 VLC 播放 720p 和 1080p H.264 视频,但由于缺乏硬件视频解码,720p 和 1080p H.265 视频确实也会出现播放时断断续续的情况。

带内存LED模式的htop
带内存LED模式的htop

那么,我什么时候使用过超过 4GB 的内存呢?就是我在 Chromium 中打开了 8 个标签页后,我使用 Gmail 帐户的 Thunderbird、使用 LibreOffice Write 的一个文本文件、带一张照片的 GIMP、Thunderbird、两个终端和 VLC(不播放视频)。结果它的分析比我最初想象的还要复杂一些,因为已用的内存 (1.92 GB) 对应程序和操作系统占用的实际内存,而缓冲区缓存是指系统用来加快 I /O 性能的RAM。因此,在具有 4GB RAM 的 树莓派 4 上,我们可以拥有 1.92GB 的已用内存和小缓冲区,而无需涉及交换。最后,还有一点你们需要注意。如果你让系统运行了更长的时间,缓存就会趋于增长从而耗尽所有的内存,因为“未使用的内存就是浪费内存”。

我还尝试在 /usr/src/hello_pi/ 中编译示例,但即使在更正新路径(/opt/usr/src)之后,编译也不会完成,并出现以下错误:


使用aptitude命令行检查时,会提示libbrcm* 库目前不存在于树莓派 OS 64 位的任何包中。这些示例的文档现在已经被弃用了,因此我觉得这些示例在短期内应该是不可以使用了。

分享这篇文章
0 评论
内联反馈
查看所有评论