Re: [Valgrind-users] Expected slowdown

[Bryan M. <bra...@go...>]

Julian Seward wrote:
>>> If that's true one simple fix would be the usual hack of moving
>>> an ExeContext in a chain one step forwards for each successful
>>> search.  Various other tables already do that.
>> You could also store the full hash value along with the list entry. This
>> adds another simple equality test (at the cost of some memory) before
>> you start to iterate up the stack trace doing the expensive full
>> comparison and should also be simple to add in.
> 
> Er .. no.  Each list contains elements with the same hash value -
> the only point of the initial hash value is to decide which list
> to use.  I did spot that the hash computation isn't 64-bit clean,
> though, which can't help.
> 
>    hash = 0;
>    for (i = 0; i < n_ips; i++) {
>       hash ^= ips[i];
>       hash = (hash << 29) | (hash >> 3);
>    }
>    hash = hash % N_EC_LISTS;
> 
> I'll look at it more later this evening.  Christoph's program doesn't
> reproduce the problem on x86 so it must be something amd64 specific.
> 

I was thinking more along the lines of

bucket = hash % N_EC_LISTS;

Use the bucket in place of the current hash value to get the right chain
and store the full hash for later comparison or is the full hash likely
to produce identical values as well?