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

[Paul Eggert <eggert@cs.ucla.edu>]

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...