3 ms·
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, wha
by 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 agoData-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.