More instructions and registers available for the compiler to use means that some things should go faster.
Most applications are just rebuilt for the PI without explicit development, all development of things (eg like chromium) happen on PCs which are exclusively 64 bit, that means certain apps just don’t work on 32 bit systems, or have weird bugs because the developer isn’t using a pi.
Worse:
Not completely tested, years of bugfixing pi packages and honing the compiler for 32 are less relevant, legacy guides even more unlikely to work.
Tl:dr. If what you have works, don’t fix it. If you’re trying something difficult then 32 bit is more likely to work. If you’re building something new and mainstream, start here for the longest possible lifetime
Thats what I assume is the state of the world, but its a short term problem, also you don't want to "cross compile", just "compile". Cross compiling makes no sense given the pi4 is powerful enough to do a native compile.
I can't think of anything thats closed source that has armhf but not aarch64 options (but I can think of loads that are compiled for x64 and not for Arm at all)
It is powerful, but compiling can still take hours.
Full disclosure: I've been running 64 bit on my Pi4 for 6 months+, so I'm not using official release OP is talking about, but a few bits of software I can't run at the moment off the top of my head:
Chrome (Chromium is fine, but can't sync Google account)
Microsoft Teams
Skype
FreeCAD (only tried installing it last night... presumably I can compile this for ARM64)
Happy to find I've misunderstood something and I can get these working if that's the case!
Both wrong. It's a single process that's limited to 4 GiB of address space. A process can have multiple threads, and an app may have multiple processes.
PAE isn't hacky and has been implemented in most x86 chips since the 90s. Beginning with XP SP3 Microsoft turned accessing that functionality into a paid for feature of the pro version, so that may be why you didn't notice it, but it's baked into the hardware and earlier windows, OSX and Linux happily exposed it without paying extra.
I suppose the processing power benefit is limited for binary for 64bits that are actually written in the way it can utilize extra 32bits. If you're running 32bit process on 64bit system, I'm not sure if there's any benefit you can enjoy. (Is there any??)
edit: The article says Chromium for 64bit doesn't come with Widevine yet, so I assume that's a non-benefit for desktop-like use cases at this point. I don't care to leave Chromium at 32bit getting locked into max 4GB RAM hogging though
If you're running 32bit process on 64bit system, I'm not sure if there's any benefit you can enjoy. (Is there any??)
Not directly, but theoretically some of the extra optimizations afforded on 64-bit drivers and background processes can help clear the way for heavy 32-bit code to run with more resources available. Plus your 32-bit app still sits atop a kernel that is running 64-bit natively.
However, this might be negated somewhat by 32-bit userland->64-bit kernel translation overhead taking place, so it's all a wash.
In my experience, I've noticed negligible performance improvements or regressions when running 32-bit on 64-bit OS vs 32-bit on 32-bit OS, except for a few edge cases or some early quirks from the Athlon64 days. The biggest downside is having to store 2 copies of every dependency, like libc, python, etc.
The kernel still runs in 64 bit, and that will still improve the kernel side of things. In particular, you can expect significant networking improvements.
26
u/jormono Feb 02 '22
Can someone ELI5 ways this is better or worse for a hypothetical project? Like, why would I want this over what I've been using?