Comment by NightMKoder | Hacker News Reader

Comment by NightMKoder | Hacker News Reader

For folks considering running 64-bit on the pi - I don’t think you need 64-bit userland. I’ve been running a 64-bit kernel on my pi with 32-bit userland perfectly fine. The few things that actually need 64-bit (I’m looking at you mongo) run in 64-bit mode via docker. That said, I’m not 100% sure how much memory overhead I have in this setup vs just running the 64-bit userland.

Technically there’s a very interesting “hybrid” abi you can try - 32 bit pointers on a 64 bit ISA. The main benefit is the extra registers that get unlocked in 64-bit mode while keeping memory usage lower. It seems there’s an attempt to do this in Debian [1]. From what I read it’s not a big win for arm though but could be big for x86 - since the ISA is very different between x86 and x86_64. Probably doesn’t matter when ram is so cheap nowadays.

Separately I’ve now got a serious case of buyers remorse. I just bought the 4gb version last week. I would have easily shelled out an extra $20 for double the ram.

[1] https://wiki.debian.org/Arm64ilp32Port

This was an interesting comparison of 32 vs 64bit performance

https://medium.com/@matteocroce/why-you-should-run-a-64-bit-...

I bought a 4gb Pi4 today, got the shipping confirmation email from the supplier, then straight away got another email from the same supplier launching sales of the 8gb one... talk about timing.

Slightly OT because neither ARM nor PI:

Linux x32 ABI, the free 5-8% performance upgrade!

[1] https://www.youtube.com/watch?v=Mw-ravkg67k&

From René Rebe of T2-SDE pre-Gentoo source-based Linux distro fame.

I occassionally watch it, and the website is deceptive because the latest builds are much newer than the website suggests.

Has anyone quantified these performance differences between full 64 bit vs 64 bit OS but 32 bit memory per process?

At 8 GiB RAM, allowing a single process to "only" use half of the available RAM really doesn't seem too limiting for most workflows. Especially considering that there's 4 CPU cores. If it's a notable hassle-free performance improvement it seems like a no-brainer for most use cases.

Depending on where the kernel/user memory map split is, each process may only be able to map 1-3GB. Unless things have changed and all mappings share a single address space?

The x32 ABI but for ARM, and maybe it will gain traction because of the oodles of Pis! Thank you for telling me.

x86 Linux had PAE mode, where OS could use large memory, but single process was limited to 32bit. There was some performance overhead.

NightMKoder's comment was referring to the x32 mode where an application uses the x86_64 ISA and registers but with a 32-bit ABI (ILP32 - int, long, pointers are 32-bit). The kernel is full 64-bit, so there is no overhead like in PAE where the kernel is 32-bit and needs to temporarily map physical addresses above 4GB (using highmem support). On the application side, x32 has some benefits over x86_32 since it has access to a larger register bank and wider registers if needed (e.g long long).

On ARM, there are patches implementing ILP32 with an A64 ISA (AArch64 mode and registers). While there probably is an improvement over the A32/T32 ISA, the benefit is not that great since the 32-bit ARM architecture already had 14 general purpose registers (AArch64 has 30).

The reason the arm64 ILP32 hasn't made it into mainline Linux is not fully justifying the software porting/maintenance cost over the benefit it brings. Full 64-bit software stack is in general a better option unless you run in a very constraint environment but, in that case, an M-class ARM CPU is probably a better option anyway.

Reply on news.ycombinator.com