The Raspberry Pi Foundation has now officially released Raspberry Pi OS 64-bit about two years after the first beta version was released.
Despite some potential performance benefits from using 64-bit code instead of 32-bit, the Raspberry Pi Foundation has resisted moving too quickly to a 64-bit OS because if it would create two separate worlds for their earlier 32-bit boards like Raspberry Pi 2 or Raspberry Pi Zero, and the newer 64-bit boards starting with Raspberry Pi 3 onwards and may confuse users besides the extra workloads.
Some of the main reasons to finally release a 64-bit version include improved software compatibility with many closed-source applications only available for arm64, and some open-source ones not fully optimized for the armhf port, some performance benefits, and the ability for a process to make use of the full 8GB RAM, removing the 3GB limit when using LPAE (Large Physical Address Extension) on 32-bit operating systems.
When I tested Raspberry Pi OS 64-bit on Raspberry Pi 4 in June 2020 I actually noted some performance regressions against Raspberry Pi 32-bit OS, and at the time there were some known issues such as the lack of hardware video decoding in VLC and Chromium. But with the first stable release, video acceleration works through Chromium and VLC, GPU acceleration works through Mesa, and hopefully, some of the performance regressions are resolved, so it can perform more or less as well, or in some cases better, than the 32-bit version.
There’s however one issue with using the 64-bit version of Chromium installed by default: the WidevineCDM library is not available making it impossible to play streaming video from premium services such as Netflix or Disney+. If that’s a must you can install the 32-bit version of Chromium instead::
|
1 |
sudo apt install chromium-browser:armhf libwidevinecdm0 |
Run the following command to reinstall the 64-bit version
|
1 |
sudo apt install chromium-browser:arm64 libwidevinecdm0 |
While in theory, Raspberry Pi 64-bit OS can be installed on any 64-bit board, the desktop version may not work very well on Raspberry Pi Zero 2 W due to the low 512MB RAM capacity, so you may be better off with the 32-bit OS in that case. The Lite version of the 64-bit OS should work fine even with 512MB RAM.
You may find more insights in the official announcement, and get the latest 64-bit OS from the Download page.
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
Quite frankly the so-called “performance benefits” of 64-bit instructions do not match my experience, I’m seeing a consistent 10-20% loss for any code switching from 32- to 64- bit. There are two reasons for this: the loss of the compact thumb2 code that was optimizing the L1 cache’s efficiency, and the removal of the conditional instructions that saved a lot of comparisons and branches. Even on my LX2 boards I’ve finally rebuilt the compilers in 32-bit because they’re way faster like this (~12%). The real benefit of the 64-bit instruction set is that it’s richer, and gives you access to crypto and SIMD extensions which can provide a tremendous performance boost on specific workloads (when the CPUs support them). And of course being able to support larger memory areas does bring large benefits, such as being able to mmap() a large file. As such I think that using 64-bit instructions is more of a long-term investment, while using 32-bit is more of a short-term efficiency choice for a board that’s not meant to evolve much.
but RPI SOCs don’t have crypto extensions – and for SIMD I only know of NEON for rpi2+ socs so where is the benefit ?
as mentioned, only if you need to run applications eating a lot of memory, or as Arnd said, it can still be a benefit compared to their 32-bit code that’s in fact ARMv6 and not as good as ARMv7.
I think it’s mainly a question of the workload, some applications either require large virtual memory areas or they benefit a ton from 64-bit integer arithmetic, and if you run any of those, you want to run 64-bit user space. For all other workloads, using 32-bit binaries gives you a smaller memory and cache footprint that usually translates into a slightly faster system.
For Raspberry Pi OS, there are two other concerns: since the 32-bit Raspbian binaries traditionally are built for ARMv6, you don’t get the benefits of thumb2 (smaller code) or NEON (faster math). The 64-bit version does not suffer as much from the code size increase since it doesn’t have thumb2 mode either, and it does have NEON available.
More importantly, the 32-bit Raspbian only ships with a 32-bit kernel (unless they fixed that), which doesn’t work well on the machines with large memory.
To get the best performance for most workloads, you would need a 64-bit kernel, and 32-bit user space built for ARMv7-A or ARMv8-A with Thumb2 and NEON enabled. It sounds like that is exactly what you do, but most others don’t even test that configuration.
> the 32-bit Raspbian only ships with a 32-bit kernel
They shipped a 64-bit kernel as /boot/kernel8.img for quite some time and you just needed to define arm_64bit=1 in ThreadX config to get this kernel loaded instead of kernel7.img (loaded on BCM2837) or kernel7l.img (RPi 4).
Thank you for the clarification, I totally missed that.
> since the 32-bit Raspbian binaries traditionally are built for ARMv6, you don’t get the benefits of thumb2
That’s a very good point that I totally overlooked, indeed! Thus their 32-bit code is actually much worse than usually found on 32-bit ARM platforms (not counting ARMv5 where thumb1 was not good at all).
> To get the best performance for most workloads, you would need a 64-bit kernel, and 32-bit user space built for ARMv7-A or ARMv8-A with Thumb2 and NEON enabled. It sounds like that is exactly what you do
Indeed 🙂 The best benefit here is that it allows to choose at the application level what architecture is best (i.e. large RAM / modern extensions => 64, optimal legacy code => 32).
I’ve noticed performing actual work is about 10% faster on 64bit versus 32 bit OS on my 4GB Pi4. Handbrake, for example is faster as is pretty much everything else. It’s been that way for over a year.
It’s very possible that such applications benefit from the increased number of SIMD registers with NEON.
> performing actual work is about 10% faster on 64bit versus 32 bit OS
You’re not comparing 32-bit vs. 64-bit but ‘software built for ARMv6’ (AKA Raspbian) with arm64 Debian right now.
Performance differences in ‘actual work’ of less than 20% you’ll not be able to notice (tasks like Handbrake taking hours being the exception).
And what almost all people forget is memory. A 64-bit userland needs (much) more memory and once swapping starts it’s game over.
What about GPU acceleration in 64 bits? It is now available?
In the past graphics acceleration was not supported on 64-bit systems (for example, for Qt QML software or openGL games)
Do not worry too much about this. Software goes where users go. Even if not available now, the simple fact that they send the “Go!” signal to users to switch to 64-bit, the rest of the ecosystem will follow.
> the rest of the ecosystem will follow.
A significant part of the RPi ecosystem is closed source and fully depends on RPi Trading Ltd. employees who hack ThreadX drivers. Without their initial work some stuff the average RPi user only knows about (secondary OS like Linux running on the ARM guest processors) simply can’t work…
gpu is working just fine.
Yes, what about the VPU?? What about repo, it’s officially a forked debian lile rpi os 32 bits or it’s remain plain debian?? Very little info.
V4l2 on aarch64 works as greatly as on the other platforms…………
Opengl gpu acceleration always worked to me on 64 bits, no idea why the upper comment regarding that.
The package base is now plain upstream Debian arm64 with their own packages on top, pulled in by /etc/apt/sources.list.d/raspi.list.
To give an idea with the ‘Lite’ image here’s the output from uname -a ; lsb_release -a ; dpkg -l | egrep -e ‘libcamera|raspi|rpi|Raspberry’: https://pastebin.com/raw/yDwmzTaY
Of course on the Desktop image their Chromium and other optimised stuff will be pulled in as well.