"Modern operating systems can now take advantage of that seemingly vast potential memory. But even 32 bits of address space won't prove adequate as time goes on."
But 64 bits should be enough for anybody.
But 64 bits should be enough for anybody.
Aarch64 on the other way...
The point was, that there will be not a problem with tagged pointers. The pointers have to be clean today when used, so those who use tagged pointers have a place in their code where they handle the cleaning.
Some very old distributed systems used 64 bit pointers where the upper bits told you what machine the data was on.
And we have Intel putting SSD card in DIMM slots. I expect there are semantics attached to those address ranges as well.
I dunno where we are after Spectre, but one of the microkernel architectures got its IPC speed by packing most processes into a couple of address spaces, only with different read write access. On preemption the TLB wasn’t invalidated (about half the cost), just modified.
These are the sorts of tricks you do when your address space is bigger than you will ever need. I expect to see more of this as time goes on. And if we ever see 128 bit pointers, expect crazy stuff like this to be de rigeur.
There are still things you could do, of course. For example, you could more or less NaN-box but rotate the bits so the tag is in the lowest bits instead of up in the exponent, then ensure all your pointers are sufficiently aligned. That would mean a perf hit on doubles to do the rotation to recover the double, but you might be right that this is not too bad in practice on modern hardware.
Well, there goes that startup idea ...
So yes, highly likely for a little while..
> I expect that to change before upgrading to 128-bit pointers.
Or the joke was wasted on me. Did you mean it will never be feasible?
I think the value of a larger pointer (immediately) would be tags, not memory density, just as it was with 64-bit systems -- my old Alpha only had 256mb of ram, and maxed out at 512mb IIRC.
Wow. What kinds of workstation tasks need this kind of memory, if I may ask?
It is popular to buy a bunch of servers (or worse, host them on AWS), a bunch of sysadmins, and so on, so you can support a couple smart analysts with some complex hadoop java streaming somethingrather, but it is much cheaper to just buy them beefy workstations and use awk: A HP Z8 G4 with 1.5TB ram is under £30k, and it's hard to get a sysadmin that has any brains for that, let alone two and servers...
??? I know of multiple high end servers with 1TiB+ memory footprints. What is your definition of high end?
Here, have a look at HP's page if you don't believe me: https://www.hpe.com/us/en/product-catalog/servers/proliant-s...
And I'd hardly consider those "high end", there are much larger memory servers out there if you want them.
I've already run into cases of programs figuring that a "64-bit" address space is basically infinite and running out of address space by trying to have tens to hundreds of thousands of 4GB memory mappings (not necessarily backed by RAM).
For global or large system level addressing 128 to 256-bits should be enough.
(note: you may want local 128-bit virtual addressing for other reasons than accessing more memory)
You don't want to share the same compact memory allocator with the malloc(3) from the other side of the galaxy, or even different city.
Yes, that's why IPv6 is as big as it is. We could fit pretty comfortably into 64 bits for a long time, really, if you assume we fairly tightly pack everybody in. 128 bits is really to give us some routing headroom, not because anyone seriously thinks we're going to use IPv6 on 2^128 distinct targets any time soon. (By the time we have a "galactic internet" it sure won't be using IPv6, not because it's bad or wrong but just because we're going to need something designed to handle the very different challenges involved.)