Comment by huntie
7 years ago
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.
You are right - they can be 0 & copy of bit 47.
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.
1 reply →
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.