[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: Bug#38708: eq vs eql in byte-compiled code
Date: Thu, 2 Jan 2020 15:12:20 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

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

reply via email to

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