|
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...
[Prev in Thread] | Current Thread | [Next in Thread] |