The Prospects for 128 Bit Processors ( John Mashey SGI 1995)

That exchange is quite a good prediction all things considered.

> Note that "minor" implementation issues like die space, routing, and gate delays, especially of 128-bit adders & shifters are non-trivial, so people aren't going to rush out and build 128-bitters for fun, just as people matched timing dates of their 64-bitters to their expected markets.

I think we're stuck with 64 bit for quite a while. The circuit size jump from 64 bit to 128 bit is significant. There's no fixed scalar or apples to apples comparison (that I'm aware of). Just for adders though, 2 bits requires 2 full adders, 4 bits requires 4 adders, 8 requires 8, etc.

Another way to look at this is that 16 bit gives addressable memory up to 65k, and quite a few programs had to deal with paging in architectures like the 8086/8088. 32 bits gave us up to 4GB addressable memory, and not it's now not uncommon that a program such as a web browser exceeds this. 64 bits would give us up to 18 exabytes of addressable memory. I'm not aware of any common programs breaking into the terabyte category (even in most research), let alone petabyte and then exabyte.

Even iterating over that many numbers becomes a large computational task. Just a quick test program:

    // gcc -O3 count.c -o count
    #include <stdint.h>
    int main(){
      uint64_t z = 0;
      for(uint64_t i = 0; i < UINT64_MAX; i++) z += i;
      return (int)(z % 2);
    }

So reflecting on that, I think the core assumption that didn't pan out is that the memory / CPU ratio will grow because we'll need more memory, hence requiring CPUs to address more than 16 EiB of data (16 EiB = 16384 PiB = 16777216 TiB of data, what 64 bits can address).

But in practice, we've produced a lot more compute. The memory / CPU ratio has increased, but most growth has been from more CPUs (and generally not shared-memory ones, but ones with their own completely separate memory space).

IPv6 is 128 bit, so we do have 128 bit ways of addressing computers, but I'd say we're still a long way from a CPU needing to address that much memory as a common case. The speed of light limits how far away memory can be from the CPU for good performance, so short of some drastically new memory technology, it seems unlikely we'll need it soon for any ordinary type of computing device.

One interesting thing with wider addresses isn't necessarily increasing itself, but features built upon the expansion. CHERI is one example of that.

Personally I'm disappointed 128-bit floating point (quadruple precision) never properly made it into CPU's (sure it appeared in some niche ones here and there, but not in what we actually use today). After all, in the 1980's they had 80-bit ones, it's not even that far off, and they had millions times less transistors then.

While probably niche and applications that need higher precision using their own custom types anyway, they'd allow cool stuff like easy to program fractals with much higher detail than now. But also, less precision loss in many applications.