Live data from Hacker News

64 bit OS Raspberry Pi4 Benchmarks

medium.com

61–70 of 104 posts

Re: 64 bit OS Raspberry Pi4 Benchmarks

#61
post #58
post #56

Noob question: What kind of optimizations are even responsible for those kinds of performance improvements? 32 bits is enough to utilize all 4 GB of the Raspberry Pi4, so I figured the only benefit of using a 64 bit OS would be to support 64 bit software. Why would a 64 bit build perform better than a 32 bit build on the same hardware?

64-bit ARM NEON (SIMD instruction set) is much more efficient vs 32-bit. And not just NEON, there are more registers as well, deeper pipeline, etc.

Also, 32-bit ARMs often (but not always) don't have hardware integer division.

Re: 64 bit OS Raspberry Pi4 Benchmarks

#62
post #17

Earlier quoted context omitted.

The flipside is-- if you have a 1GB pi, you're going to be wasting a whole lot of RAM on wider pointers, and you may be more constrained by RAM than CPU throughput. (Also, 64 bit Pi is not nearly as well supported as 32 bit currently. Does hardware GL work yet? What about if you're going to do MIPI, etc?) IMO it's worth waiting for a little more maturity.

I have not used or had a need for hardware GL. Don't even know what MIPI is. I use it as very cheap bare metal. Still plan to use 3 of them as Ceph monitors.

It used to be Mobile Industry Processor Interface [1] but no longer is used as an acronym.

High-speed serial links for driving displays and cameras in cell phones, originally. Proprietary.

[1] https://en.m.wikipedia.org/wiki/MIPI_Alliance

Re: 64 bit OS Raspberry Pi4 Benchmarks

#63
post #58

Earlier quoted context omitted.

64-bit ARM NEON (SIMD instruction set) is much more efficient vs 32-bit. And not just NEON, there are more registers as well, deeper pipeline, etc.

Also, 32-bit ARMs often (but not always) don't have hardware integer division.

Integer division is mandatory from v7VE on upwards (so roughly Cortex-A9, A15 and later), and it's definitely in the 32-bit support of any 64-bit capable core. If Raspbian is compiling its packages for the lowest common denominator arm v6 cpu some Pis have, then you'd get some slowdown from division being an out-of-line call (to library code that can use the hw insn), but you'd see that part of the speedup just from building for 32-bit but optimised for newer cores than v6, I think.

Re: 64 bit OS Raspberry Pi4 Benchmarks

#64
I’ve been running Ubuntu on most of mine for a while now, but I go back to Raspbian now and then for the hardware support (graphics, in particular, are a bit of a pain, but I’ve also had issues with the built-in Wi-Fi). My “lab” Pi 4 is on Raspbian also because I like noodling in Mathematica (which I don’t think you can get in ARM64 at all for any distro).

It would be awesome to have a decent ARM64 SBC with a good GPU (able to drive 2 4K monitors and run Firefox/VS Code). Any recommendations from the non-Pi crowd?

Re: 64 bit OS Raspberry Pi4 Benchmarks

#65
post #17

Earlier quoted context omitted.

The flipside is-- if you have a 1GB pi, you're going to be wasting a whole lot of RAM on wider pointers, and you may be more constrained by RAM than CPU throughput. (Also, 64 bit Pi is not nearly as well supported as 32 bit currently. Does hardware GL work yet? What about if you're going to do MIPI, etc?) IMO it's worth waiting for a little more maturity.

Has nobody tried to implement an aarch64 equivalent of the "x32" ABI? That is, using the 64-bit instruction set but keeping pointers 32 bits long?

Not sure about Linux, but Apple has for Apple Watch…

Re: 64 bit OS Raspberry Pi4 Benchmarks

#66
post #60

The CPU of the Raspberry Pi 4 is the only 64-bit ARM chip I've ever seen that doesn't include native AES instructions. As a result, it's much lower performance for network or disk encryption use cases. Up until the RPi 4 I thought AES instructions were a part of AArch64, but I was wrong. Such a weird omission to make on (I expect) Broadcom's side. All other 64-bit ARM SBCs just have it, even the low cost ones.

They are a recommended extension. I expect that the crypto instructions are not present on the RPi3/4 because of legal reasons, to allow it to be exported to Iran and such...

Re: 64 bit OS Raspberry Pi4 Benchmarks

#67
post #63

Earlier quoted context omitted.

Also, 32-bit ARMs often (but not always) don't have hardware integer division.

Integer division is mandatory from v7VE on upwards (so roughly Cortex-A9, A15 and later), and it's definitely in the 32-bit support of any 64-bit capable core. If Raspbian is compiling its packages for the lowest common denominator arm v6 cpu some Pis have, then you'd get some slowdown from division being an out-of-line call (to library code that can use the hw insn), but you'd see that part of the speedup just from…

>If Raspbian is compiling its packages for the lowest common denominator arm v6 cpu some Pis have

It is definitely the case, the official Raspbian images support Raspberry Pi 1.

Re: 64 bit OS Raspberry Pi4 Benchmarks

#68
post #63

Earlier quoted context omitted.

Also, 32-bit ARMs often (but not always) don't have hardware integer division.

Integer division is mandatory from v7VE on upwards (so roughly Cortex-A9, A15 and later), and it's definitely in the 32-bit support of any 64-bit capable core. If Raspbian is compiling its packages for the lowest common denominator arm v6 cpu some Pis have, then you'd get some slowdown from division being an out-of-line call (to library code that can use the hw insn), but you'd see that part of the speedup just from…

Cortex-A9 does not have hardware division. Cortex-A7 and Cortex-A15 onwards do.

Re: 64 bit OS Raspberry Pi4 Benchmarks

#70
post #60

The CPU of the Raspberry Pi 4 is the only 64-bit ARM chip I've ever seen that doesn't include native AES instructions. As a result, it's much lower performance for network or disk encryption use cases. Up until the RPi 4 I thought AES instructions were a part of AArch64, but I was wrong. Such a weird omission to make on (I expect) Broadcom's side. All other 64-bit ARM SBCs just have it, even the low cost ones.

AES is quite efficient in software. The RPi4 should be able to saturate its network connectivity many times over with SW AES.

A Pentium II 200 MHz could saturate 100 Mbps with AES-128[1], RPi4 has 4 x 1400 MHz cores (with 64-bit ALU & NEON available).

[1] https://www.di.ens.fr/~granboul/recherche/AES/timings.html

edit: There are RPi4 AES and other benchmarks here in this "openssl speed" paste: https://gist.github.com/HimaJyun/f05d3017dfb05a4ccb0def010bb... - indicates 50-80 MB/s = 400-640 Mbps per core.

Post reply on HN