[pansa2]

> This allows unboxing the vast majority of floats, which leads to big speedups on float-heavy benchmarks.

NaN-boxing allows all floats to be unboxed though. The main benefit of the self-tagging approach seems to be that by boxing some floats, we can make space for 64-bit pointers which are too large for NaN-boxing.

The surprising part of the paper is that "some floats" is only a small minority of values - not, say, 50% of them.

[skybrian]

A small minority, but apparently it includes all the floats you’re likely to use. It seems the insight is that you only need 8 bits of exponent in most cases. (And single-precision floating point only has 8 bits of exponent.)

Most double-precision floats are never used because they have high exponents.

[bee_rider]

Got take, but a double with only 8 bits of exponent actually seems kind of nice, you get the extra precision but it can be cast down to a single and you only lose precision; you don’t have values that are outside the range of singles.

[pansa2]

> A small minority, but apparently it includes all the floats you’re likely to use.

Sorry, I meant a small minority need to be boxed - all the floats you're likely to use can remain unboxed.

[adgjlsfhk1]

50% means you only get 1 tag bit.

also you totally can fit 64 bit pointers inside a NaN. 46 bit pointers are only 48 bits and you have 53 bits of NaN payload. (you also could get an extra 3 bits if you only allow storing 8 byte aligned pointers unboxed)

[pansa2]

> 50% means you only get 1 tag bit.

That's enough to distinguish between "unboxed float" and "something else", where the latter can have additional tag bits.

> [64-bit] pointers are only 48 bits and you have 53 bits of NaN payload.

The paper specifically talks about support for "high memory addresses that do not fit in 48 bits". If you don't have to handle those high addresses, I don't think this approach has any benefits compared to NaN-boxing.

[dzaima]

Of note is that even if you have some massive ≥2^48 data sources, you could still quite likely get away with having NaN-boxed pointers to within the low-size heap, with an extra indirection for massive data. This only would break apart if you managed to reach around 2^45 distinct referenceable objects, which you probably shouldn't ever have (esp. in a GCd language).