The Raspberry Pi 4 with 8GB RAM launched a couple of weeks ago together with the beta version of Raspberry Pi OS 64-bit. Note that you should currently use the 32-bit version of Raspberry Pi OS (previously known as Raspbian) as the 64-bit still has bugs and missing features, but I want to find out the current progress, so I installed raspios_arm64-2020-05-28/2020-05-27-raspios-buster-arm64.zip and had no problem to boot the board.
Raspberry Pi OS 64-bit System Information
After going through the setup wizard in the desktop environment to configure the language, time, networking, etc…, and make sure the OS is updated, I checkout some information:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
pi@raspberrypi:~ $ cat /proc/cpuinfo processor : 0 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 ... Hardware : BCM2835 Revision : d03114 Serial : 10000000694c8ae2 Model : Raspberry Pi 4 Model B Rev 1.4 |
I do have a Raspberry Pi 4 Model B Rev 1.4 with 8GB Memory (revision: d03114), the image comes with a 64-bit Linux kernel:
|
1 2 |
pi@raspberrypi:~ $ uname -a Linux raspberrypi 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux |
and we do get a 64-bit rootfs.
|
1 2 |
pi@raspberrypi:~ $ file /bin/busybox /bin/busybox: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=fdf7b3dd496e8fd678a0bda5540f9fae4d313d8f, stripped |
All good.
Known issues
Before starting the review, let’s make ourselves aware of known issues:
1) There is no hardware video acceleration in VLC or Chromium
2) libraspberrypi0, libraspberrypi-dev and libraspberrypi-doc have been moved out of /opt/vc/* and into /usr/* instead (making it more standard). Any code built against these libraries will require changing to refer to a more standard location (/usr/lib/ rather than /opt/vc/lib)
3) Due to 2) Many packages that expect libGLESv2.so libEGL etc will require rebuilding.
4) raspberrypi-bootloader and raspberrypi-kernel contain useless non-64bit binaries and is missing the work done to minimise the delay between files being deleted and installed to /boot
5) There is no Wolfram Mathematica built for AArch64
6) Minecraft shim layer requires rebuilding to cope with 2)
7) VLC needs rebuild (not available)
8) VNC server not rebuilt yet for 64bit
Raspberry Pi OS 64-bit Benchmark
Most benchmarks are not sensitive to RAM capacity (unless swapping is involved), but I still installed sbc-bench to compare with the results I got with Raspberry Pi 4 (1GB RAM) using Raspbian Buster 32-bit:
|
1 2 |
wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod +x sbc-bench.sh |
SBC Bench results:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
sudo ./sbc-bench.sh sbc-bench v0.7.2 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time... Done. Checking cpufreq OPP... Done. It seems neither throttling nor frequency capping has occured. Memory performance: memcpy: 2503.6 MB/s (0.2%) memset: 3359.5 MB/s (0.5%) 7-zip total scores (3 consecutive runs): 5083,5065,5099 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 38070.54k 40669.85k 41716.22k 42029.40k 42131.46k 42177.88k aes-128-cbc 38065.38k 40746.26k 41775.96k 42064.21k 42229.76k 42292.57k aes-192-cbc 32294.31k 34105.22k 35048.28k 35303.42k 35351.21k 35351.21k aes-192-cbc 32254.74k 34136.98k 35043.33k 35301.38k 35367.59k 35367.59k aes-256-cbc 27986.06k 29351.96k 29962.33k 30127.79k 30173.87k 30179.33k aes-256-cbc 27986.74k 29372.25k 29969.24k 30119.25k 30160.21k 30157.48k Full results uploaded to http://ix.io/2paq. Please check the log for anomalies (e.g. swapping or throttling happened) and otherwise share this URL. |
Note that I’m using KKSB aluminum case so cooling is not an issue. We can see the comparison in the chart and table below (higher is better for all results).
| Raspberry Pi 4 @ 1.5 GHz Raspbian 32-bit – 1GB RAM | Raspberry Pi 4 @ 1.5 GHz RPI OS 64-bit beta – 8GB RAM |
|
|---|---|---|
| memcpy (MB/s) | 2,662.5 | 2,503.6 |
| memset (MB/s) | 3,436.9 | 3,359.5 |
| OpenSSL AES-256-CBC 16K | 64,951.64k | 30,157.48k |
| 7-zip | 5,397* | 5,082.33 |
* The 7-zip result is for an earlier test with Raspberry Pi 4 + heatsink (not KKSB) since in the KKSB review 7-zip run out of memory and did not complete.
As we can see the 64-bit OS is slower in all four results. The differences are marginal for memset/memcpy, around 6% lower for 7-zip, and a massive 50+% for AES-256 hash. We should not really be surprised by the latter, since last January, somebody compared Debian OS 32-bit and 64-bit on Raspberry Pi with similar results for AES-256-SBC 16KB in sbc-bench script, but somehow SHA1SUM (SHA1 hash function) was much faster with the 64-bit OS.
Features Testing and Multi-tasking on Raspberry Pi OS 64-bit
Now let’s try to run common programs to find out potential bugs or limitations, and see when the total memory usage goes above 4GB RAM which would make the switch to 8GB RAM worthwhile.
I’ve monitored the total memory usage with htop (used + buffers + cache), and first ran Chromium browser with multiple tabs, YouTube, and Facebook game (Candy Crush Saga), loaded VLC, Thunderbird, LibreOffice with .odt file, and GIMP with a photo.
I also ran glxgears -info to confirm graphics acceleration is working (was already obvious from Candy Crush Saga),
|
1 2 3 4 5 6 |
glxgears -info Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. GL_RENDERER = V3D 4.2 GL_VERSION = 2.1 Mesa 19.3.2 GL_VENDOR = Broadcom |
and played 720p and 1080p videos (H.264/H.265) in VLC. You can check all steps in the video below.
To summarize, Raspberry Pi OS 64-bit is already fairly stable. I had no big troubles with Chromium, except YouTube really starts to struggle with 1080p videos due to the lack of hardware video decoding at this stage, and Candy Crush Saga (HTML5) really takes a long time to load, but once it’s loaded the games plays smoothly. I could play 720p and 1080p H.264 videos with VLC, but both 720p and 1080p H.265 videos were really choppy due to lack of hardware video decoding.
So when did I get more than 4GB RAM used? After I opened eight tabs in Chromium, Thunderbird with a Gmail account, one text file with LibreOffice Write, GIMP with one photo, Thunderbird, two terminals, and VLC (no videos playing). The results are a bit more complicated to analyze than one may first think, as used memory (1.92 GB) corresponds to the actual memory taken by the programs and OS, while buffers and cache refer to RAM allocated by the system to speed up the I/O performance. So on a Raspberry Pi 4 with 4GB RAM, we could have 1.92GB used memory and small buffers and cache without swap being involved. Finally, if you leave the system run for a longer period time, the cache will tend to grow to use up all memory, as “memory unused is memory wasted”.
I also tried to build the samples in /usr/src/hello_pi/, but even after correcting for the new path (/opt to /usr/src) the build would not complete with errors such as:
|
1 2 3 4 5 6 7 8 |
triangle.c: In function ‘init_ogl’: triangle.c:119:11: error: unknown type name ‘EGL_DISPMANX_WINDOW_T’ static EGL_DISPMANX_WINDOW_T nativewindow; ^~~~~~~~~~~~~~~~~~~~~ ... /usr/bin/ld: cannot find -lbrcmGLESv2 /usr/bin/ld: cannot find -lbrcmEGL /usr/bin/ld: cannot find -lopenmaxil |
The libbrcm* libraries are currently not present in any packages in Raspberry Pi OS 64-bit as checked with aptitude command line. The documentation for the samples is deprecated, so I don’t expect those to work any time soon.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
As for the lower OpenSSL benchmark numbers with 64-bit this is a 2-step issue:
OK, this looks to be because of mitigations against attacks like Spectre and Meltdown which are not needed in Cortex-A53 since those cores are immune. It does not affect most of other Armv8 processors because cryptographic extensions are implemented. Maybe Broadcom BCM2711B1 processor is coming…
> Maybe Broadcom BCM2711B1 processor is coming…
But adding Crypto Extensions would cost “$millions” according to those who know everything 😉
omg, i wonder how much cheap allwinner is losing on those cryptos…
An extra Hard Crypto needs extra chiparea: Say 0.2$ per chip. About 3 Mill. Pi4s were sold. Target is > 10 Mill.. So the Hardcrypto costs about 10,000,000 * 0.2 = 2 Mill$. In the short run the new QPUs may be accelerate the Softcrypto (currently – to my knowledge – based on arm-cores/neons)
Oh my…
Dropping linux in favour of bare metal with rust risc-v on fpga and all to make it more secure than such evil like wireguard in kernel…
#gotoheise #buzzwordbingo
So what real world use does RPI see for 8gb that actually needs 8gb ?
Because they can?
It’s all just the result of a huge conspiracy to force rpi into 64bit?
Who would of thought you would need such power to turn a led, on and off.
Hihi
I thought new usecase is zoom conferencing homeoffice workstation?
Jean-Luc, FWIW, recent C4 benchmarks: http://ix.io/2nKO
Summary, it pays to have the crypto extensions if you plan on doing crypto. Faster memory interfaces are good. 4 slower cores at 2GHz beat 4 faster cores at 1.5GHz.
I’m curious about the differences in memory speeds. In particular the graphical memory tests are very odd. The strange difference in speed between memset and memcpy between the two platforms.
Yes processors with Armv8 crypto extension are over an order of magnitude faster for AES than the few ones without.
Memory speeds are about the same, or do you mean the differences between memcpy and memset per se, i.g. not between the two platforms?
The difference between their ratios of cpy/set vary a lot. I’m curious if that’s a property of the memroy interface/memory type/timing, etc. It just seemed odd.
First, the A55 has a new and improved memory controller that certainly helps here. But even without this I already noticed during my compile tests that the RPi4’s memory performance is abnormally low compared to comparable devices made of RK3399 for example (which is already not that strong of a beast). And this almost doesn’t improve when you overclock the device to 2.0 GHz so there’s really something with the controller itself or with the internal datapath. By the way I remember noticing smaller memory latency than with other devices, leading me to think that the controller might be optimized for short bursts to favor latency over bandwidth.
Thanks, Willy. If they optimized the Rpi4 memory interface for latency over BW, then they failed at that, too. The C4 shows better latency performance as well–just just as much as you’d expect for the higher bandwidth of the C4. Unless I’m reading it wrong. (Sorry, I’ve been doing DDR4 memory latency calculations on my PC and my brain is a bit fried)
There’s always adamantium. Pi 4 is a really strong offering for the price. Except they leave the sub $40 market completely empty.
Who said that ? A new zero (rebuild Pi3A, zero-formfactor, < 15-20$) may be possible bevor the end of the year.
So is it better to setup Ubuntu 20.04 (I need only server edition, bash) as they claimed that officially support Pi4? I mean in case when I really want 64bits OS?
This was tested in June 2020, so they may have solved a few things by now.
At this point using Ubuntu 20.04 64-bit or Raspberry Pi OS 64-bit is probably just a matter of preference.