Comment by maxwell
7 years ago
"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.
7 years ago
"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.
Other people have pointed out how much memory 64bits provides, but the real problem is when we go from 48bits to 64bits. 48bits provides 256TB of address space. Right now amd64 only uses the bottom 48bits for pointers and some systems take advantage of this for things like NANboxing. I don't really know the numbers, but losing the ability to NANbox will probably come with a performance hit.
NaN-boxed or tagged pointers have to be processed before use anyway - amd64 enforces canonical pointers, even if the high bits are unused (they have to be set to 1).
Aarch64 on the other way...
What's your point? A few bitwise operations are far quicker than reading from memory. Also are you sure that the high bits must be 1? I thought they had to be the same as the 48th bit.
2 replies →
NANboxing isn't the only strategy for type tagging. We've been using tagged pointers in 32-bit land for decades. I doubt the perf hit here is going to be significant.
The reason NaN-boxing is popular for JS is that the only numeric type in JS (per spec, though JITs can sometimes improve on this) is 64-bit IEEE float, and it sure is nice if your value format can represent those directly without requiring a separate heap allocation.
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.
Exponentials being what they are, the 32 -> 64 jump buys us a lot of headroom.
IIRC from the ZFS promo blurb, the energy required to flip 2^128 bits is enough to boil the oceans (assuming a maximally efficient process).
I don't quite reach that number. According to Landauer's principle the minimum energy required to flip a bit is 0.0172 eV. Times 2^128 is ~10^18 J. The first google result for boiling all oceans puts it around 10^29 J. Even at realistic energy values for current hardware (10 fJ), we are still 5 orders of magnitude short of boiling all oceans.
Seems like if we keep boiling, that's about what it takes to boil lake Baikal.
> we are still 5 orders of magnitude short of boiling all oceans.
Well, there goes that startup idea ...
That was thus marketing BS, thanks for doing the math :-)
16 million terabytes will be a lot of RAM for at least a couple of decades.
Hey, some of us could even run our favourite Electron app at that point
Or maybe even two of those - side by side ;)
Moving beyond a 64-bit architecture will allow manipulation of memory address spaces that are larger than 16 Exabytes. Even high-end servers today do not contain more than 1TB of physical memory. It would take several decades if not more for memory densities to become high enough to begin to reach the boundary that 64-bit addressing limits computers.
So yes, highly likely for a little while..
You can have an AWS instance with up to 12 TB of RAM: https://aws.amazon.com/blogs/aws/now-available-amazon-ec2-hi...
Current x86 architectures only use 48 bits for addressing. That’s still enough to address ~280TB of RAM. I expect that to change before upgrading to 128-bit pointers.
128 bits are nearly enough to address every atom in the Universe. Such pointers are mostly a waste of memory space.
> 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?
People where I work have workstations with more than 1TB of ram.
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.
> People where I work have workstations with more than 1TB of ram.
Wow. What kinds of workstation tasks need this kind of memory, if I may ask?
5 replies →
> Even high-end servers today do not contain more than 1TB of physical memory.
??? 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.
64-bit addressing is much more than enough for many decades to come or even forever!
In fairness, what we have right now is 48-bit addressing, not 64-bit.
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 local addressing inside a computer 16 exabytes is enough.
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)
"(note: you may want local 128-bit virtual addressing for other reasons than accessing more memory)"
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.)
Intergalactic (or interplanetary even) networking is more likely to be UUCP like than TCP like, but that doesn't mean it won't need addressing, and that addressing might as well be IPv6. Maybe we can get packets larger than 1500 bytes though.
I think there are roughly 2^166 atoms on earth (translating 10^50 if I didn't mess up my maths). So clearly we don't need 256 bit addressing for any system!
The problems of allocating memory addresses in global scale requires distributed probabilistic addressing or otherwise inefficient address space distributions.
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.
You will regret this.