[PATCH] D41993: [ELF] - Change shift2 constant of GNU_HASH from 6->11.

[Rui Ueyama via llvm-commits]

On Thu, Jan 18, 2018 at 12:41 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >>>> I feel like this change looks a bit too arbitrary. If we can prove
> that it
> >>>> is in general an improvement, I'm fine with this change, but even
> George's
> >>>> experiment shows that 11 may not be an optimal number.
> >>>>
> >>>> Probably what we should do is to try different shift2 numbers to see
> if
> >>>> which one yields the best result on the fly. I'll try to see if this
> isn't
> >>>> too slow.
> >>>
> >>>Note that his computed score doesn't correlate with performance in all
> >>>cases. In particular I got bad results with 1, but that has a high
> >>>score.
> >>>
> >>>Cheers,
> >>>Rafael
> >>
> >> Yeah, it has a high score for test using random symbol names.
> >> I had bad results with 1 when run llvm-check too.
> >>
> >> Though the patch which calculates the score with the same algoritm in
> runtime
> >> worked good for llvm-check. I did not check which values it normally
> selects for llvm case.
> >
> >If I understand it correctly, a patch to maximize your score that tries
> >every shift2 value will effectively maximize how many set bits we have
> >in the bloom filter, no?
> >
>
> Yes.
>
> >It almost feels that that is the opposite of what we want.The more 0s that
> >are left in the bloom filter the more likely it is that the dynamic
> >linker can skip this .so at runtime.
>
> Right. But I am thinking about it in a bit different way:
> We have MaskWords constant to control the bloom filter size.
> With it we should setup optimal bloom filter size.
>
> We have Shift2 to control something else (distribution of bits probably).
> I think that it is probably OK to tweak Shift2 to optimize one thing and
> MaskWords to optimize another one. No need to care about that Shift2 sets
> too much bits, it is MaskWords job to keep enough free bits, no need
> to optimize single parameter for many things at once.
>

I don't believe that spending time on "tuning" shift2 value is a good idea
because I doubt that that is theoretically meaningful. If my understanding
is correct, changing that value doesn't have any significant effects.

The bloom filter for the .gnu.hash table is a two-bit bloom filter. To
choose two bit locations, we compute one hash value H and create two hash
values H1 and H2 in the following manner :Assume a 64-bit machine. Bits
H[0,5] are always used for computing the first hash H1. Bits H[Shift2,
Shift2 + 5] are used for computing the second hash H2.

As long as the hash function produces evenly distributed hash values,
choosing bits [6, 11] isn't different from choosing other bits, say [15,
20]. No Shift2 greater than 5 should be better than any other Shift2 values
in theory.

Am I missing something?

Then if above is right, then it is OK to set up Shift2 in the way described
> while
> MaskWords has optimal/good value.
>
> >The value 0 feels like a bad special case because then there is only one
> >bit, which makes a hit more likely.
> >
> >If you have a patch that can try every non zero value of shift2, would
> >you mind trying selecting the value that produces the most 0s and the
> >most 1s?
> >
> >Thanks,
> >Rafael
>
> Sure, I'll try.
>
> George.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180118/86849e7d/attachment.html>