RPi Benchmarks: 32- Vs 64-bits article on HaD

[Timescale]

Found this on Hackaday https://hackaday.com/2020/01/28/raspber ... s-64-bits/.

I do not think anybody doubted that 64-bit would be a bit faster, but especially the network benchmarks are shocking really!

[ejolson]

Found this on Hackaday https://hackaday.com/2020/01/28/raspber ... s-64-bits/.

I do not think anybody doubted that 64-bit would be a bit faster, but especially the network benchmarks are shocking really!

Compared to my tests

https://www.raspberrypi.org/forums/view ... 9#p1533989

it looks like Wireguard has improved all around over the last few months. Note I also had a cheap gigabit switch in the way while Matteo's setup is not clear.

I'm currently using Wireguard with a number of machines and find it much nicer than IPSec. Hopefully it is more secure as well.

In defense of 32-bit Raspbian, it's also worth mentioning that Python, which wasn't benchmarked in that article, runs slower in 64-bit mode.

[Timescale]

it looks like Wireguard has improved all around over the last few months.

I have OpenVPN running on my pi-hole/(air)printer server/air play device/DNSoverHTTPS service/do everything network servant, but suddenly I'm very interested in Wireguard.

[ejolson]

it looks like Wireguard has improved all around over the last few months.

I have OpenVPN running on my pi-hole/(air)printer server/air play device/DNSoverHTTPS service/do everything network servant, but suddenly I'm very interested in Wireguard.

I think people happy with OpenVPN are using it to connect upstream over a relatively-slow residential internet connection. Secure clustering and filesharing over a multi-user multi-use local area network needs something faster. Wireguard seems a little faster than IPSec on AMD 64-bit compatible machines, however, making use of AES in hardware or any type of cryptographic offload on the networking card itself may still favour IPSec. Since the Pi has no special cryptographic acceleration, Wireguard is a clear winner in that case.

Once you have a cluster of Pi computers interconnected with Wireguard, there is no need to use a separate system-area network for the cluster. This is convenient in situations where the existing network is fast but includes devices such as smart televisions, mobile phones and Windows computers that do not meet the same levels of security.

[Timescale]

I think people happy with OpenVPN are using it over a relatively-slow residential internet connection.

I was quite happy with OpenVPN and I have gigabit ethernet and gigabit glass fiber to the home. However, I'm not using it to connect 2 networks together but rather for use for my mobile devices when I'm on the move. It it means I have access to my network and dev station on all networks and all my mobile devices are able to use my pi-hole and DNS over HTTPS features on my network.

Thus far I found the speed on say the train rather good as using OpenVPN means better connectivity than using it by itself. I also did not find the load on the RPi4 to be terrible.

After some more reading on the subject, I concluded that regarding VPN's I'm far from a poweruser and OpenVPN for now is fine.

[phil995511]

50% more performance in 64 bits under dhrystones, that's a lot !!

Several of us requested a full 64-bit Raspbian OS several months ago. The developers refused to do this, claiming that it would not bring more performance ;( Which is clearly not the case, but that we already knew.

The Hybrid version that we are offered 32/64 Bits does not allow to run for example the browser Google Chrome, it is therefore impossible to watch OS Apple TV +, Netfix, etc, under Raspbian ... And then there has more and more developers of other software that no longer make 32-bit versions which is handicapping for us end users.

This situation is very disappointing, I dare to hope that the people of the Raspberry foundation wake up and finally offer us Debian 10 Buster in full 64 Bits version very soon. I'm sure a lot of people are ready to help them if it's just a matter of missing human resources.

It is true that there are other RPi4 compatible OSes that work in 64 Bits like Ububtu and Gentoo; but first of all as a user you have to love these OS to use them and you can only install them on SD card (unless I am mistaken). Indeed the Boot on Hard-Disk / SSD in USB 3 is still not functional if we do not use the Noobs boot loader for this...

Regards.

[pica200]

It's a mixed bag. 64 bit will be faster in most cases but it will bottleneck with RAM intense applications because of the single channel RAM with 32 bit bus. A bigger L2 cache may help but it's a question of costs. SRAM is very expensive.

[jamesh]

50% more performance in 64 bits under dhrystones, that's a lot !!

True. My suspicion is that the the code has been better optimised for 64 (perhaps NEON etc)

Several of us requested a full 64-bit Raspbian OS several months ago. The developers refused to do this, claiming that it would not bring more performance ;( Which is clearly not the case, but that we already knew.

People have been requested 64bit for MUCH longer than that. We've never refused to do it, clearly, at some point we will need to move to it, and that is why a considerable amount of time and money has been spent on things like the KMS driver, which is necessary to fully make the move.

The Hybrid version that we are offered 32/64 Bits does not allow to run for example the browser Google Chrome, it is therefore impossible to watch OS Apple TV +, Netfix, etc, under Raspbian ... And then there has more and more developers of other software that no longer make 32-bit versions which is handicapping for us end users.

We are completely aware of the limitation of the current system. Although I doubt this handicapping of users is particularly heinous - most people seem to get on fine.

This situation is very disappointing, I dare to hope that the people of the Raspberry foundation wake up and finally offer us Debian 10 Buster in full 64 Bits version very soon. I'm sure a lot of people are ready to help them if it's just a matter of missing human resources.

I think its rather rude of you to say this. You have NOT THE FOGGIEST IDEA of what we are doing internally.

It is true that there are other RPi4 compatible OSes that work in 64 Bits like Ububtu and Gentoo; but first of all as a user you have to love these OS to use them and you can only install them on SD card (unless I am mistaken). Indeed the Boot on Hard-Disk / SSD in USB 3 is still not functional if we do not use the Noobs boot loader for this...

Regards.

Some of the work that done on those will surely help us to move to 64bits. But remember that they don't give all the features of the current 32bit systems, it's the last 10% that takes all the time. Imagine the furore if we released a 64bit OS that did not do as much as the previous 32 bit release! No camera, no LCD etc.

[phil995511]

Why use a 64-bit OS on your Raspberry Pi 4 ? Because performance is better than 32-bit, says Red Hat employee :

https://raspberry-pi.developpez.com/act ... -de-tests/

[jamesh]

Why use a 64-bit OS on your Raspberry Pi 4 ? Because performance is better than 32-bit, says Red Hat employee :

https://raspberry-pi.developpez.com/act ... -de-tests/

And again, they have neglected to take in to account the fact we still sell devices that are 32bit and the need to support them on the same install.

64bit will turn up. Eventually.

[ejolson]

I think its rather rude of you to say this. You have NOT THE FOGGIEST IDEA of what we are doing internally.

To avoid situations where the customer has not the foggiest idea, the marketing department often puts together an executive-level roadmap designed to indicate obvious areas of development which are actively being worked on. For example, a statement such as "rewriting the Python core object system so moving to 64-bit mode no longer results in a 20% slow down--expected: Third quarter of 2020" would put certain minds at ease. Note the above example is completely made up and may or may not be false.

People will have more confidence that a sufficient number of next-generation items are being worked on, if an official marketing roadmap is provided. That should reduce feature-request threads started by well-meaning members of the fan base convinced they can help their favourite computer company by asking for a Pi 4B with 8GB RAM. Enthusiastic discussion of USB boot may also be reduced along with the current mantra meditating on 64-bit Raspbian.

On the other hand, in my opinion, things are also fine the way they are.

[jamesh]

We have never released any sort of product roadmap, because dates are always missed and we do not wish to give anyone ideas of what we are up to. But I suppose it should be fairly obvious that we are working quite hard on on stuff, including [REDACTED], [REDACTED], KMS, [REDACTED] and [REDACTED] so it's all very exciting.

[sakaki]

In the meantime, one interim solution (which thanks to ShiftPlusOne is now a deb in the official (*) Raspbian repo!) is raspbian-nspawn-64: this allows you to install and run regular 64-bit Debian Buster packages in a lightweight container on your RPi3B/3B+/4B (under the official 64-bit kernel, alongside your regular 32-bit Raspbian 'host' userspace).

Installation just requires, in essence (for more information, please see this post):

Code: Select all

pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get install -y raspbian-nspawn-64

After which you should be able to open a 64-bit Debian Buster shell:



Apps installed in the container have desktop launchers automatically created for them, so that they can be run just like (and alongside) regular 32-bit apps. By default, regular user home directories are shared between host and guest O/S, but you can also e.g. 'mask' out the ~/.config used in the guest, to prevent pollution between e.g. different versions of Chromium. You can even run 64-bit Docker inside the container if you like.



(*) Please note: although it is now in the official repo, this package is not maintained by RPi engineers, so please don't ask them for support regarding it. Instead, please direct any such questions to me, either by posting in this thread, or by email, to sakaki@deciban.com

hth, sakaki

[ag123]

i think there are some pros and cons with 64 bits, compute that use large word sizes e.g. 32 bits, 64 bits (e.g. double precision) would benefit significantly. however, for compute that deal with fragmented bits and bytes, they may not benefit as much. in addition, data may need to be 8 byte (64 bits) aligned instead of 4 bytes (32 bits) aligned. this may use significantly more memory if say you need to use 8 bytes aligned structures to store 4 bytes ints. 64 bit apps may be more memory hungry for this reason. hence it is a tradeoff between memory use and speed

thanks for sharing nspwan, i think it'd really help for cases where 64 bits really helps

[pica200]

Nah, the alignment requirements (of the CPU) are pretty much the same as AArch32. The biggest hit are the pointers which are all (essentially) 64 bits which doubles size and it can change alignment of structures they are stored in wasting bytes (worst case). The improved instruction set seems to counter this well enough.

Or to summarise:
A struct of 2 4 bytes big ints takes the same space in AArch32/64. But every pointer doubles in size on AArch64.

[chwe]

Why use a 64-bit OS on your Raspberry Pi 4 ? Because performance is better than 32-bit, says Red Hat employee :

https://raspberry-pi.developpez.com/act ... -de-tests/

And again, they have neglected to take in to account the fact we still sell devices that are 32bit and the need to support them on the same install.

64bit will turn up. Eventually.

why? you simply can deliver 2 images, one 32bit supporting everything and one image 64bit supporting RPi3 upwards (and for the simplicity, I assume you don't support those RPi2 with the 64bit SoC with a 64bit OS too).

Some of the work that done on those will surely help us to move to 64bits. But remember that they don't give all the features of the current 32bit systems, it's the last 10% that takes all the time. Imagine the furore if we released a 64bit OS that did not do as much as the previous 32 bit release! No camera, no LCD etc.

Just declare it WIP and place a short note on the downloadpage with DSI, CSI and *random feature* are currently not supported. Even I would defend your "Told you so, it's stated on the downloadpage that *random feature* is currently not supported." And I guess I'm not your strongest supporter here... Packet wise, 64bit will be much less of an effort to support cause you're then on an architecture which is officially supported by debian (whereas ARMv6 HF for the Pi1 and Zero isn't).

If and how much you gain from a 64bit raspbian over the current 32bit is then up to your project and up to the user to decide. I'm sure there are projects which would benefit from 64bit (I would assume those are mostly headless) and there are projects where it doesn't make sense to switch but the users have the possibility to so.

[rpdom]

why? you simply can deliver 2 images, one 32bit supporting everything and one image 64bit supporting RPi3 upwards

It's not just a case of two images. There's also the tens of thousands of packages in the repositories to build and take up storage on all the mirrors around the world.

Plus other reasons have been stated as to why 64 bit isn't ready yet.

[jamesh]

Why use a 64-bit OS on your Raspberry Pi 4 ? Because performance is better than 32-bit, says Red Hat employee :

https://raspberry-pi.developpez.com/act ... -de-tests/

And again, they have neglected to take in to account the fact we still sell devices that are 32bit and the need to support them on the same install.

64bit will turn up. Eventually.

why? you simply can deliver 2 images, one 32bit supporting everything and one image 64bit supporting RPi3 upwards (and for the simplicity, I assume you don't support those RPi2 with the 64bit SoC with a 64bit OS too).

Some of the work that done on those will surely help us to move to 64bits. But remember that they don't give all the features of the current 32bit systems, it's the last 10% that takes all the time. Imagine the furore if we released a 64bit OS that did not do as much as the previous 32 bit release! No camera, no LCD etc.

Just declare it WIP and place a short note on the downloadpage with DSI, CSI and *random feature* are currently not supported. Even I would defend your "Told you so, it's stated on the downloadpage that *random feature* is currently not supported." And I guess I'm not your strongest supporter here... Packet wise, 64bit will be much less of an effort to support cause you're then on an architecture which is officially supported by debian (whereas ARMv6 HF for the Pi1 and Zero isn't).

If and how much you gain from a 64bit raspbian over the current 32bit is then up to your project and up to the user to decide. I'm sure there are projects which would benefit from 64bit (I would assume those are mostly headless) and there are projects where it doesn't make sense to switch but the users have the possibility to so.

Thanks for telling us what to do, we really appreciate it.

[scruss]

Timescale, I'd take a look at Roy's Raspberry Pi Benchmarks thread. He's the OG of careful benchmarking and has been doing it for longer than most of us (including me) have been alive.

[pica200]

why? you simply can deliver 2 images, one 32bit supporting everything and one image 64bit supporting RPi3 upwards (and for the simplicity, I assume you don't support those RPi2 with the 64bit SoC with a 64bit OS too).

Because more effort. Trust me, i would love a full 64 bits kernel and userland Raspbian but they have other things to do than maintaining 2 official images and 2 repos.

If you can't wait try this or one of the inofficial distributions:
viewtopic.php?f=63&t=232417&start=125#p1621085

[chwe]

why? you simply can deliver 2 images, one 32bit supporting everything and one image 64bit supporting RPi3 upwards

It's not just a case of two images. There's also the tens of thousands of packages in the repositories to build and take up storage on all the mirrors around the world.

Plus other reasons have been stated as to why 64 bit isn't ready yet.

you simply fetch them from the debian repo cause arm64 compared to ARMv6 hf is natively supported by debian.. More or less the only reason raspbian had to rebuild all this packages was that they either had to fall back to armel which is ARMv6 soft float which would performance wise be hurting or build on their own with the vfp2 flag set. If they would've gone for multiple images long time ago, raspian could've fetched from debian starting with the RPi2 which was first an ARMv7 hf and later replaced by the ARM64.

Thanks for telling us what to do, we really appreciate it.

always with pleasure. arguing with hypothetical claims what users will complain about will end in hypothetical answers how to avoid those hypothetical complains...

Because more effort. Trust me, i would love a full 64 bits kernel and userland Raspbian but they have other things to do than maintaining 2 official images and 2 repos.

If you can't wait try this or one of the inofficial distributions:
viewtopic.php?f=63&t=232417&start=125#p1621085

the kernel is already there, see @sakaki' post. and the userland see above.. I had a 64bit debian running on a pi 2-3 weeks after the Pi arrived at home. There's not much special sauce needed to debootstrap a debian compile a kernel and glue everything together to create an working image..

[andrum99]

Found this on Hackaday https://hackaday.com/2020/01/28/raspber ... s-64-bits/.

I do not think anybody doubted that 64-bit would be a bit faster, but especially the network benchmarks are shocking really!

That's not a like for like comparison - 32-bit Raspbian is not the same as 32-bit Debian, so to compare 32-bit Raspbian with 64-bit Debian is not ideal. Also, it's not clear how they built 64-bit Debian for the Pi 4B and how it was configured - there isn't actually an official Debian build for the Pi 4B, as far as I can tell.

[pica200]

@chwe
Well then. You seem to know how to maintain images and make sure the packages on the repos work. Make us a fully working 64 bit, Debian based Raspbian image and make sure it's as stable as the official one

[ejolson]

There is an entire area on this forum devoted to Debian for Raspberry Pi. A reasonable thread on how to create an bootable image is

viewtopic.php?f=50&t=261181

Since Debian already maintains binary packages for ARM64, there is no need to build them all over. They just work.

[ejolson]

We have never released any sort of product roadmap, because dates are always missed and we do not wish to give anyone ideas of what we are up to. But I suppose it should be fairly obvious that we are working quite hard on on stuff, including [REDACTED], [REDACTED], KMS, [REDACTED] and [REDACTED] so it's all very exciting.

As per the announcement

viewtopic.php?f=91&t=267080

see also

https://www.raspberrypi.org/blog/raspbe ... g-utility/

we now know what one of the projects marked [READACTED] above was and that the availability date is today!

Woohoo! I wonder which [REDACTED] stands for 64-bit userland in Raspbian.