Since packages are derived from Debian (which supports arm 64), I assume pretty much all packages you can install from the Raspbian repos for 32 bit will still be available.
Which begs the question of what is even the point of having their own distro anymore. Why not just push a bit more to land their changes upstream in linux, and make debian the default noobs install, while providing the option to do all the other OS's as well.
I've said this before, that instead of focusing on building a custom distro everyone would benefit if they instead focused on just enabling all the other distro's and OS's. Pretty much everything, including windows runs on the darn thing, its the closest piece of HW in the arm ecosystem (other than the server class machines) to a random PC motherboard when it comes to just about working with any given OS.
There's sense in trying to keep their diff from upstream fairly minimal, but I can see value in having some differentiation - if nothing else, the RPi foundation probably wants to ship Pi-branded images (default background, application menu icon, that kind of thing). Also, there might be issues around nonfree requirements, although I'm having a surprisingly hard time finding information about that; I know booting the Pi requires a nonfree firmware blob, but I'm not sure whether there are any ex. wifi driver issues.
That said, yes one would very much hope that everyone can work together to make the diff between Debian and its downstreams as small as possible given the constraints that each party operates under.
Raspberry PI OS 32bit is compiled for ARMv6 to support the orginal Raspberry pi. I wonder what impact on benchmarks there would be compiling for ARMv7 hence only supporting Raspberry pi 2 and later?
I've been operating 64-bit kernels and user-space for at least a couple of years for embedded and network and server usage and not experienced anything to even remind me it's 64-bit rather than 32-bit.
I've used both the original Raspbian 64-bit builds and plain Debian 64-bit with the few required RaspberryPi specific tools added in. Kernels are all self-built (cross-compiled) keeping up with mainline Linux.
TLDR: Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%
I suspect most of the performance improvements came not from being "64-bit", but rather from the new instructions in aarch64 (and even in armv7) over armv6 (which is what the 32-bit Raspbian has to use to be backwards compatible with the first Raspberry). So I don't think it is entirely appropriate to frame the performance improvements due to it going from "32-bit" to "64-bit".
In fact, hypothetically assuming the same instruction set, 64-bit can cause performance degradation over 32-bit, particularly in memory-bound benchmarks, because the size of memory pointers and default int size will take up twice as much space, which puts stress on the limited cache space, which will generate additional off chip memory accesses.
I'm sorry when I was in university there were still SPARC64 machines around, which use the "ILP64" where the default int size increased to 64 bits, so that must have been why I was taught that the default int size increased when going to 64-bit arch.
Sun-shipped 64-bit Solaris has 32 bit int and it's in the LP64 column of the Wikipedia table. The entry of a ILP64 HAL systems version is about this other niche Solaris port for HAL designed chips that was not commonly used in universities (or anywhere, for that matter).
> I suspect most of the performance improvements came not from being "64-bit", but rather from the new instructions in aarch64 (and even in armv7) over armv6 (which is what the 32-bit Raspbian has to use to be backwards compatible with the first Raspberry). So I don't think it is entirely appropriate to frame the performance improvements due to it going from "32-bit" to "64-bit".
Possible; IIRC, we had the same thing on x86 because the jump to AMD64 meant that you could depend on certain extensions (SSE2?) that didn't exist on all previous processors but which were present on all 64-bit processors. So it became a split where code compiled for 64-bit CPUs knew it could depend on those extensions without even needing a runtime check, which was nice. That said, my understanding is that for data-heavy workloads it really does help to move twice as much data per operation.
> Using a 64-bit kernel (arm_64bit=1) just takes away 50MB of RAM, the worst choice is to combine 64-bit kernel and 64-bit userland since everything relevant get slower, same tasks require much more memory and the device will start to swap if low on memory or even kill processes due to out of memory.
> As a rule of thumb you need almost twice as much RAM with a 64-bit userland compared to 32-bit with the same programs/services running. [1]
That's not supported by any data posted there. You'd have to have almost all of your memory filled will pointers to achieve 2x increase which just doesn't happen in reality. Looking at a large application like Firefox https://www.raymond.cc/blog/mozilla-firefox-64bit-build-perf... you get ~30% increase.
19 comments
[ 2.8 ms ] story [ 54.0 ms ] threadAnybody know how software support is looking for 64Bit? OS support is good but presumably the software itself needs to be arm 64 compiled too?
I've said this before, that instead of focusing on building a custom distro everyone would benefit if they instead focused on just enabling all the other distro's and OS's. Pretty much everything, including windows runs on the darn thing, its the closest piece of HW in the arm ecosystem (other than the server class machines) to a random PC motherboard when it comes to just about working with any given OS.
That said, yes one would very much hope that everyone can work together to make the diff between Debian and its downstreams as small as possible given the constraints that each party operates under.
I've used both the original Raspbian 64-bit builds and plain Debian 64-bit with the few required RaspberryPi specific tools added in. Kernels are all self-built (cross-compiled) keeping up with mainline Linux.
That's quite impressive!
In fact, hypothetically assuming the same instruction set, 64-bit can cause performance degradation over 32-bit, particularly in memory-bound benchmarks, because the size of memory pointers and default int size will take up twice as much space, which puts stress on the limited cache space, which will generate additional off chip memory accesses.
'int' size stays the same. 'long' gets bigger (on LP64 platforms).
Apart from that, I would agree with your assessment.
I'm sorry when I was in university there were still SPARC64 machines around, which use the "ILP64" where the default int size increased to 64 bits, so that must have been why I was taught that the default int size increased when going to 64-bit arch.
Possible; IIRC, we had the same thing on x86 because the jump to AMD64 meant that you could depend on certain extensions (SSE2?) that didn't exist on all previous processors but which were present on all 64-bit processors. So it became a split where code compiled for 64-bit CPUs knew it could depend on those extensions without even needing a runtime check, which was nice. That said, my understanding is that for data-heavy workloads it really does help to move twice as much data per operation.
> As a rule of thumb you need almost twice as much RAM with a 64-bit userland compared to 32-bit with the same programs/services running. [1]
[1]: https://github.com/ThomasKaiser/sbc-bench/blob/master/Result...
That doesn't make sense; going 64-bit should only double the size of pointers, it shouldn't touch the size of code or data in memory.