Is there any reason we wouldn't keep advancing the computer bits beyond 64? "640K ought to be enough for anybody" has held up nicely, for example.
(a large virtual address space is of course useful on its own, for instance never reusing a memory address, but we're not even close at scratching the 64-bit barrier - e.g. AFAIK x86-64 CPUs have are limited to 48 bits virtual and 52 bits physical address range).
We might be there. And 128 bits is a lot of bits. You know what bit width you need to represent twice as many states as a 64 bit value?
That's right, a 65 bit value.
Regarding the non-SIMD side of x86, what are good driving needs to process 128-bit values among the normal instruction stream?
- 128 bits is 16 bytes, and that's a decent maximum length for many textual identifiers. These can be loaded, compared, and processed with single instructions now and possibly be processed without intermediate memory accesses.
- It would be super convenient to load a GUID/UUID or IPv6 in a single register/instruction I guess. Would Intel get an `RDUUIDV4` instruction and be able to generate them natively?
- A bigger space for `mmap()` could have interesting possibilities.
- 64 bits of additional randomization available for memory paging could make security techniques like ASLR a bit better.
For UUIDs, 16-byte short strings and IPv6, there's no real reason the SIMD units couldn't do the work there. (Granted the existing vector units may be a bit short on features for working "across" lanes - I'm not sure how capable they are at dealing with null-terminated C strings for example).
In principle at least (and allowing for some snags around memory alignment), C++ std::strings with the short string optimisation (which stores the string's data on the local stack, if it's less than a certain number of bytes) can already be loaded into vector registers and indeed never materialised as memory at all. How much this happens in pratise I wouldn't like to say, but it's not that hard to roll your own stringid_16 or whatever with conversion operators.
That statement still isn't false today.