Re: Bug#38708: eq vs eql in byte-compiled code

[Paul Eggert]

On 1/2/20 4:27 AM, Pip Cet wrote:

> For what it's worth, I'm not seeing that effect, and it seems too
> large to me to be easily explicable.

I'm also puzzled. I reproduced the effect on two smallish hosts (Fedora 
31, Ubuntu 18.04.3) running sequentially, but not on a larger one when 
running with 'make -j14' (RHEL 7.7). I'll look into it a bit more. Could 
be a cache-size issue.
> I might be mistaken, but our hash tables never shrink, do they? That
> sounds like a potential problem to me, particularly for people who
> mess about with gc settings; but I haven't been able to produce a
> problem in practice with your patch.

You're right they don't shrink. However, on today's machines I expect 
that the only problem would be that a hash table too large for its 
number of entries would not cache as well.

> > * Should we try hash-consing floats too? Maybe it wouldn't be as slow as we
> > thought, for typical computations anyway....
>
> I think the answer is yes here...
>
> > * The attached patch could probably be sped up a bit by supporting sets as well
> > as mappings at the low level, since bignum_map is really just a set of bignums.
> > Not sure it's worth the effort, though.
>
> if it's also yes here.

More things for me to look into, I suppose...