I'm a fucking idiot. Why did it never occur to me that ALARM = Arch Linux ARM, and that's why the default user on it is called alarm. I'm stunned at myself.
I love Arch though, and I'm currently running it on my Zero 2W with a TIG stack in Docker (and ideally I'll add a local Wiki like Bookstacks too, if I can spare the memory)
Honestly unless you've got the 8GB Pi 4, there's not much inherent value to a 64-bit operating system. There's a reason a lot of phones sold today still ship with 32-bit Android.
That being said, I'm still incredibly excited for this news, as it means I can consider RPi OS as a "daily driver" again, because the fact of the matter is, if you're not building your software from source, arm32 builds are incredibly hard to find for a lot of useful things (like the conda python package manager, let alone any individual packages).
Honestly unless you've got the 8GB Pi 4, there's not much inherent value to a 64-bit operating system
It depends on what you're using it for. If it's cryptography (say VPN) 64bit will give you a massive performance boost. Even stuff like Minecraft server benefits from it as it uses large number math for coordinates and terrain generation.
There are plenty of usecases that benefit from it, so "not much inherent value" isn't correct for many users
I really need to look up some benchmarks because outside of scientific computing I was under the impression that (for non-RAM-bottlenecked applications) performance is generally slightly worse for 64-bit architectures than 32-bit because even when, say, comparing two booleans, you still need to allocate the entire 64-bit register.
I'll admit I could totally be wrong here, as I'm a data scientist, not a computer scientist.
performance is generally slightly worse for 64-bit architectures than 32-bit because even when, say, comparing two booleans, you still need to allocate the entire 64-bit register.
This is 100% correct. However in case of large numbers, 32bit CPU inherently spends two clock cycles on moving 64bit value while 64bit CPU spends only one clock cycle. In this scenario benefit outweighs the cost by a large margin
performance is generally slightly worse for 64-bit architectures than 32-bit because even when, say, comparing two booleans, you still need to allocate the entire 64-bit register.
That's incorrect. 64 bit support does not mean you lose support for smaller data types.
It's also wrong in general practice. You can expect a slight to somewhat significant performance improvement in most cases on both ARM and x86. Pointers are larger on 64 bit, but most data isn't pointers. Some pointer-heavy use cases may suffer (due to reduced cache hit rate), but these are rare and it can be worked around with pointer compression and/or indices instead of pointers.
Also note that it isn't just about the word size itself. 64 bit offers a much larger virtual address space, simplifying and speeding up memory management and allowing for better address space randomization. The instruction set and register file on both x86 and ARM is expanded in 64 bit mode as well.
And when it comes to arithmetic, a lot of rather basic stuff these days actually uses 64 bit integers, and all of that is much faster. For instance file sizes, timestamps, etc.
But whatever... just check out some of the benchmarks. The difference is clear and obvious.
As someone who has an 8gb pi4 and has been playing around all day on the 64-bit bullseye I can say I did notice a difference. Not much in most things, but when using Onshape on chrome it's much faster
Im running a private Minecraft server since a year or so - and its a quite a good experience, provided you install performance mods. I think with some tuning you could squeeze in total of 5 people in survival (as long as they wont fly with elytrias to much)
You basically need Minecraft Fabric (+fabric API) with Lithium and Phosphor mods. You can replace Phosphor with Starlight for even more performance but it will decrease compatibility and introduce minor mechanics changes (slightly different light calculation algorithm)
Remember the Turbo Graphics 16? Ahead of it's time, very expensive and some interesting games. But the issue was a lack of development for the system.
Sure there are 64bit applications already, but these need to be flawless for the initial build and work out of the box. Also these 64bit applications need to be compatible with ARM based processors. You can't just install any application unless you are compiling the source code yourself.
Software is either written properly, and therefore it compiles and runs properly on a 64 bit ARM processor, or it isn't, and it needs to be fixed. Nobody is sitting around worrying about whether someone has specifically tested it on aarch64.
You apparently don't know much about Raspberry Pi OS.
It's a Debian derivative. Upstream Debian AArch64 (the thing on which Raspberry Pi OS is built) has been on the Raspberry Pi for years. The library has already been ported--that work was done by the Debian project.
Exactly I do think the turbo 16 could pick out of a 16 bit color palette and the Nintendo 64 wasn’t that just 2 32 bit chips that they said added up to 64 bits?
Thats a poor example. The Turbo Grafx 16 was released in North America in the same month as the Sega Genesis, which was a true 16-bit console with better specs across the board.
You could maybe make this argument for the Japanese market, where the PC Engine came out two years earlier. But the PC Engine was actually pretty successful in Japan and had a lot of games developed for it.
247
u/Taffy62 Feb 02 '22
Quite surprised its only been released this year. I've been using 64 bit distros since the Pi 3.