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

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 18 00:41:57 PST 2018


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

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.


More information about the llvm-commits mailing list