> could run 64-bit operating systems, which could address more than 4GB of RAM

I just want to vent how insane it is how the x86 ecosystem moved to 64 bit because Microsoft refused to support physical address extensions in XP. It was completely artificial, it was not a technical limitation. Hell, we really have no excuse to be on 64 bit even today - the improved integer and floating precision is nice, but few people cared about that. With PAE, you are only limited by the per-application address space... which you are still limited by today if you are running a 32 bit program. And in the Windows ecosystem, since there is so much less free software and no package management, everything is distributed as a 32 bit binary to be compatible across the board.

Which means in practice nobody ever needed 64 bit. And those that did had business reasons to do so. It is true that Itanium failed because Intel was ignorant of the massive inertial resistance to trying to bring tools across architectures - there is a reason OS/2 still exists, and that is just cross-OS, you can still use the same ASM at least. And you would always be surprised how many enterprise programs are ASM bound somewhere because some unholy desecration of coding practices goes on in the bowels of that non-source-controlled shared repository of suffering.

But I'm talking about the consumer space here - if AMD64 took off as the Xeon class of 2004 that would have been fine, but we made this transition for pretty much no reason at all. I have no idea why Microsoft thought making Windows 64 bit for the Vista release (there was 64 bit XP, but that was really rare and business focused) was easier than just supporting PAE.

But that is happening again today. Kind of in reverse, though. Or maybe it is just a precedent that was set? Apple has now opened the floodgates for ARMv8, and now everyone and their mother wants 64 bit buzzwords on their products while their phones still ship with 3GB of less of memory, and their architecture again supports PAE without issue.

Because there are performance ramifications here. You can fit less into your cache lines when every address takes up twice the space. There is a reason to try fitting your data in the smallest format possible. You end up with more pages in aggregate from all the wasted space, and thus consume more memory implicitly. And we never even got real 64 bit - x86 chips are still physical 48 bit, because somewhere along the lines it was realized "64 bits is ludicrous amounts of memory".

I think the best part is that memory limitations are also solvable problems. If your program hits its memory limit (ie, a 32 bit binary with 4GB addressing) you can just fork a process instead of a thread, and suddenly you double your working space. It is insanely rare to have an active working set of more than 4GB where that data needs to be address-local available for access or else you suffer huge slowdowns, and even more so in routines where you cannot load balance to delegate processes that manage ranges of values that get that big.

Likewise, if you hit a kernel address limit (remember, with PAE, you can get anything from a magnitude to thousandfold increases in available physical memory) your problem is so huge it makes sense to have it worked on by a server farm compute cluster. Unless you tried to voodoo all that circuitry together into some supermassive NUMA system (sounds painful) which wouldn't make any sense anyway because trying to abstract away network interconnects between disparate nodes at that scale has so much latency trying to treat it like memory when it is as slow as flash storage is redundant.

....

Ok, tangential rant over. I just think 64 bit is such a stupid buzzword waste of time, and its crazy that the industry has gone deep end on it for so long because it exploits some cultural tick in people that bigger is better. No, in practice it really does not "hurt" to have, but we (at least the consumer class, and 99% of business use cases) never needed it in the first place, really.