Comment x32 flopped (Score 2) 15
The larger address space can be useful in some applications
Such as high-resolution image editing and high-definition video editing. Compared to a web browser, these aren't quite as amenable to splitting an application into numerous "content processes," each with their own separate 2 GB RAM.
but most applications are already bloated and having bigger pointers hasn't improved matters for this bloat problem.
For a while, Linux supported an x86-64 ABI called "x32" that limits each process's address space to 2 GB so that more pointers will fit in the processor's data cache. It didn't become popular, in part because of a need to load three versions of the system libraries: 32-bit i686, x86-64, and "x32". In addition, porting x86-64 applications to use less pointer-heavy containers gave most of the cache advantage that "x32" would have provided. This includes switching from linked lists to gap buffers (or other dynamic arrays), from B-trees to T-trees, or from pointers to indices in a pool. Rust in particular has encouraged use of appropriately sized indices as a workaround for the borrow checker.
For systems that want to access more than 2GB-4GB of physical RAM, there has long been PAE/PSE-36 that permit mapping 64GB physical address space to a 32-bit virtual space.
There's a widespread misconception that a 32-bit operating system is limited to 3 GB of physical RAM. I think this comes from Microsoft's practice of requiring drivers for 32-bit Windows Server to support PAE as a condition for certification, but not drivers for 32-bit Windows desktop. I seem to remember 32-bit desktop Linux being more PAE-friendly. PAE and content processes are how Firefox for 32-bit Linux managed to hang on this long.