Checking Out Raspberry Pi OS 64-Bit on Raspberry Pi 4 8GB RAM

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/ 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:

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:

and we do get a 64-bit rootfs.

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 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:

SBC Bench results:

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.64k30,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.

Click to Enlarge

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),

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.

htop with Memory LED mode

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:

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.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

19 Replies to “Checking Out Raspberry Pi OS 64-Bit on Raspberry Pi 4 8GB RAM”

  1. As for the lower OpenSSL benchmark numbers with 64-bit this is a 2-step issue:

    • BroadCom never licensed ARMv8 Crypto Extensions for those VideoCore hybrid SoCs as used with the Raspberries and as such they are missing from each and every RPi so AES has to be done on the CPU cores. With those Crypto Extensions scores would be at least ten times higher.
    • OpenSSL 1.1 performance degradation with 64-bit explained:


    1. 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…

        1. 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)

    2. 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

    1. Because they can?
      It’s all just the result of a huge conspiracy to force rpi into 64bit?

  2. Jean-Luc, FWIW, recent C4 benchmarks:
    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.

    1. 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?

      1. 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.

        1. 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.

          1. 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)

    2. There’s always adamantium. Pi 4 is a really strong offering for the price. Except they leave the sub $40 market completely empty.

      1. Who said that ? A new zero (rebuild Pi3A, zero-formfactor, < 15-20$) may be possible bevor the end of the year.

  3. 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?

    1. 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.

Leave a Reply

Your email address will not be published.