3 ms·

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.

flohofwoe 2y ago
At some point we'll run out of atoms in the solar system for the physical memory ;) (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).
- sounds 2y ago
  Yes, it was 48 bits virtual but Intel is starting to introduce SKUs with support for 57 bits of virtual address space: https://en.wikipedia.org/wiki/Intel_5-level_paging https://en.wikipedia.org/wiki/Intel_5-level_paging
VyseofArcadia 2y ago
Exponential growth. 640k is obviously not enough. Nor is double that. Or double that. Or double that. But keep doubling long enough, and eventually the length of time before you need to do it again will be considerable. 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.
aydyn 2y ago
> 640K ought to be enough for anybody That statement still isn't false today.
RiverCrochet 2y ago
It kinda has been advancing, but the advancement has been happening on the SIMD/SSE/AVX side of things (up to 512 now). 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.
- Earw0rm 2y ago
  Data-level parallel processing (or SIMD vector width) is a different thing to address space width. If you want to see some _really_ wide units, look at GPUs. 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.

flohofwoe 2y ago

At some point we'll run out of atoms in the solar system for the physical memory ;) (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).

sounds 2y ago
Yes, it was 48 bits virtual but Intel is starting to introduce SKUs with support for 57 bits of virtual address space: https://en.wikipedia.org/wiki/Intel_5-level_paging https://en.wikipedia.org/wiki/Intel_5-level_paging

VyseofArcadia 2y ago

Exponential growth. 640k is obviously not enough. Nor is double that. Or double that. Or double that. But keep doubling long enough, and eventually the length of time before you need to do it again will be considerable. 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.

aydyn 2y ago

> 640K ought to be enough for anybody That statement still isn't false today.

RiverCrochet 2y ago

It kinda has been advancing, but the advancement has been happening on the SIMD/SSE/AVX side of things (up to 512 now). 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.

Earw0rm 2y ago
Data-level parallel processing (or SIMD vector width) is a different thing to address space width. If you want to see some _really_ wide units, look at GPUs. 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.