[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.
- Re: Making 'eq' == 'eql' in bignum branch, (continued)
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/01
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/01
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/03
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/03
- Re: Making 'eq' == 'eql' in bignum branch, Pip Cet, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch, Stefan Monnier, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch, Pip Cet, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch, Stefan Monnier, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch, John Yates, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/10
- Re: Making 'eq' == 'eql' in bignum branch,
Paul Eggert <=
Re: Making 'eq' == 'eql' in bignum branch, Elias MÃ¥rtenson, 2018/08/10
Re: Making 'eq' == 'eql' in bignum branch, Stefan Monnier, 2018/08/19