4 ms·

It is not too difficult to imagine for virtual memory. Servers with high storage density are right up against the current virtual memory limits such that you ca

It is not too difficult to imagine for virtual memory. Servers with high storage density are right up against the current virtual memory limits such that you can't mmap() storage as it is. Not that you'd want to mmap() if you cared about performance. Similarly, the largest data models have been in the exabyte range for a while. It is just a matter of time before they are not byte-addressable using a 64-bit integer. I think there is more utility in 128-bit ALUs than 128-bit pointers, as a practical matter.

zepearl 5y ago
> Not that you'd want to mmap() if you cared about performance. So far I never used mmap (no usecase that pushed me to find alternatives for the usual open&seek), but I was always curious about it. Your statement made me search & find this ( https://unix.stackexchange.com/questions/474926/how-does-memory-mapping-a-file-have-significant-performance-increases-over-the-s https://unix.stackexchange.com/questions/474926/how-does-mem... ) => interesting. Thanks :)
- BeeOnRope 5y ago
  You might also consider this Q&A whose answers contain several reasons mmap might be faster, and several why it may be slower: https://stackoverflow.com/questions/45972/mmap-vs-reading-blocks https://stackoverflow.com/questions/45972/mmap-vs-reading-bl...
- IgorPartola 5y ago
  mmap has a bunch of other use cases other than opening files. Shared memory, fast memory allocation, disk-backed memory regions. I believe it was invented after the gun that shoots both forwards and backwards failed to deliver on its fatality quota.
phoe-krk 5y ago
A machine word/pointer as wide as 72 bits would already solve a lot of problems that appear in e.g. dynamic languages nowadays, such as an inability to represent an IEEE double float (64 bits wide) as a value without any sort of type tagging. Still, I don't think anyone nowadays would settle for a non-power-of-2 machine word size, even if just for backwards compatibility and even if a pointer is limited to e.g. 72 bits out of all 128. If that is the case, then another use could be a "fat pointer" that was proposed somewhere in the C world to avoid passing raw pointers without their lengths.You could pass a length of an array along with its address as long as the length of your array can fit in e.g. 56 bits, which would be enough for most use cases if we feel like going into the "640kB is enough for everyone" route again.
- convolvatron 5y ago
  if you lay out your virtual memory space correctly on a little endian machine you can use the denorm space (assuming you don't care about underflows) for the actual memory and have floats and the rest of your world coresident in 64 bits.
- titzer 5y ago
  JSC, Chakra, and Spidermonkey use NaN-tagging for values; 32 bit integers, 52-bit pointers, and 64-bit doubles are all encoded into one word, with the former two using encodings that fall into the NaN space.

zepearl 5y ago

> Not that you'd want to mmap() if you cared about performance. So far I never used mmap (no usecase that pushed me to find alternatives for the usual open&seek), but I was always curious about it. Your statement made me search & find this ( https://unix.stackexchange.com/questions/474926/how-does-memory-mapping-a-file-have-significant-performance-increases-over-the-s https://unix.stackexchange.com/questions/474926/how-does-mem... ) => interesting. Thanks :)

BeeOnRope 5y ago
You might also consider this Q&A whose answers contain several reasons mmap might be faster, and several why it may be slower: https://stackoverflow.com/questions/45972/mmap-vs-reading-blocks https://stackoverflow.com/questions/45972/mmap-vs-reading-bl...
IgorPartola 5y ago
mmap has a bunch of other use cases other than opening files. Shared memory, fast memory allocation, disk-backed memory regions. I believe it was invented after the gun that shoots both forwards and backwards failed to deliver on its fatality quota.

phoe-krk 5y ago

A machine word/pointer as wide as 72 bits would already solve a lot of problems that appear in e.g. dynamic languages nowadays, such as an inability to represent an IEEE double float (64 bits wide) as a value without any sort of type tagging. Still, I don't think anyone nowadays would settle for a non-power-of-2 machine word size, even if just for backwards compatibility and even if a pointer is limited to e.g. 72 bits out of all 128. If that is the case, then another use could be a "fat pointer" that was proposed somewhere in the C world to avoid passing raw pointers without their lengths.You could pass a length of an array along with its address as long as the length of your array can fit in e.g. 56 bits, which would be enough for most use cases if we feel like going into the "640kB is enough for everyone" route again.

convolvatron 5y ago
if you lay out your virtual memory space correctly on a little endian machine you can use the denorm space (assuming you don't care about underflows) for the actual memory and have floats and the rest of your world coresident in 64 bits.
titzer 5y ago
JSC, Chakra, and Spidermonkey use NaN-tagging for values; 32 bit integers, 52-bit pointers, and 64-bit doubles are all encoded into one word, with the former two using encodings that fall into the NaN space.