Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches

[Pip Cet <pipcet@gmail.com>]

Hello, Stefan.

On Wed, Aug 22, 2018 at 8:46 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > As for `eq' and `eql', what I thought Stefan proposed was to keep a
> > hash value in struct Lisp_Bignum, which is calculated lazily the first
> > time the bignum is compared to another bignum with `eq', at which
> > point we might as well point out to the user that portable code would
> > require `eql'. That sounds to me like it would be much cheaper than a
> > hash table, but if there are objections to it we can still implement
> > it without guaranteeing it for the future in the documentation.
>
> No, that's definitely not what I was proposing.  I was proposing an
> actual hash-table.

I'm sorry, I totally misread what you wrote. No, you weren't proposing
anything like that.

> What you're suggesting is problematic in that it
> assumes `eq` will do something special for bignums, which implies `eq`
> is not just `==` in C.

Well, it isn't `==' if we're building with
--enable-check-lisp-object-type, so the problems would be memcmp or
hashing memory that might contain Lisp_Objects. I'm not aware of any
places that do either of those.

I've got something running and things appear not to fail
catastrophically right away, at least, with EQ changed to include an
extra condition for "overloaded" objects. Assuming some compiler
smarts, NILP wouldn't suffer, and EQ wouldn't suffer if one side is
known to have a normal type. I doubt the performance hit will be
measurable; if anything, the if-fixnum-do-this-if-bignum-do-that code
we have right now might be worse for caches than making the bignum
code a cold function.