[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making 'eq' == 'eql' in bignum branch

From: Paul Eggert
Subject: Re: Making 'eq' == 'eql' in bignum branch
Date: Fri, 10 Aug 2018 13:48:10 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Pip Cet wrote:
That sounds promising! However, I wonder whether NaN-boxing isn't the
right thing to do once we have bignums (on platforms that support it,
by limiting pointers to 48 bits like x86-64 does).
I worry that NaN-boxing is less portable. Won't it have problems, for example, on a system that uses ASLR and where randomized virtual addresses exceed the 2**52 limit?

I suppose, though, that if all the Javascript guys are doing NaN boxing then we can live in their shadow.
the only real disadvantage is Qnil is no
longer an all-zeroes pattern. I believe that's true for 61-bit float
"immediates" as well, though, because they need the all-zero tag bits.

Actually, Qnil is still all-zeroes with my patch. XFLOAT removes the Lisp_Float tag bits before treating the resulting Lisp_Object value as a double. I expect this costs an instruction with XFLOAT, and that it's worth it to keep NILP fast.

We can play a similar trick with NaN boxing, so that Qnil is all-zeros there too. For example, we could complement all the bits in a Lisp_Object value before treating it as a double. So I don't view this as being a major advantage for the approach I suggested.

I also wonder how many of the non-immediate floats are infinities, or
other numbers that have all low-order mantissa bits set.

Infinities have the significand bits all zero, no? I'm skeptical that this is a profitable way to explore.

I don't see how any of this applies to
32-bit platforms with 32-bit EMACS_INTs. On those, we cannot have
float immediates or NaN boxing.

We can if we're willing to limit ourselves to 'float' precision for Emacs floats and at most 2**22-or-so distinct non-numeric objects. That might be doable. However I would rather not spend a lot of time worrying about tuning 32-bit EMACS_INT platforms.
61-bit floats would mean
giving up IEEE compliance and surprising the occasional user who wants
it. That's a very high price to pay for saving a few GCs.

RMS had a different opinion; he didn't think full IEEE compliance was worth all that much trouble <https://debbugs.gnu.org/32405#47>. Although I was originally striving for IEEE compliance, I'm becoming more inclined to try things along those lines as it should indeed be faster and I doubt whether Emacs users care all that much about full IEEE.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]