<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 18, 2018 at 12:41 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>>> I feel like this change looks a bit too arbitrary. If we can prove that it<br>
>>>> is in general an improvement, I'm fine with this change, but even George's<br>
>>>> experiment shows that 11 may not be an optimal number.<br>
>>>><br>
>>>> Probably what we should do is to try different shift2 numbers to see if<br>
>>>> which one yields the best result on the fly. I'll try to see if this isn't<br>
>>>> too slow.<br>
>>><br>
>>>Note that his computed score doesn't correlate with performance in all<br>
>>>cases. In particular I got bad results with 1, but that has a high<br>
>>>score.<br>
>>><br>
>>>Cheers,<br>
>>>Rafael<br>
>><br>
>> Yeah, it has a high score for test using random symbol names.<br>
>> I had bad results with 1 when run llvm-check too.<br>
>><br>
>> Though the patch which calculates the score with the same algoritm in runtime<br>
>> worked good for llvm-check. I did not check which values it normally selects for llvm case.<br>
><br>
>If I understand it correctly, a patch to maximize your score that tries<br>
>every shift2 value will effectively maximize how many set bits we have<br>
>in the bloom filter, no?<br>
><br>
<br>
</span>Yes.<br>
<span class=""><br>
>It almost feels that that is the opposite of what we want.The more 0s that<br>
>are left in the bloom filter the more likely it is that the dynamic<br>
>linker can skip this .so at runtime.<br>
<br>
</span>Right. But I am thinking about it in a bit different way:<br>
We have MaskWords constant to control the bloom filter size.<br>
With it we should setup optimal bloom filter size.<br>
<br>
We have Shift2 to control something else (distribution of bits probably).<br>
I think that it is probably OK to tweak Shift2 to optimize one thing and<br>
MaskWords to optimize another one. No need to care about that Shift2 sets<br>
too much bits, it is MaskWords job to keep enough free bits, no need<br>
to optimize single parameter for many things at once.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Am I missing something?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then if above is right, then it is OK to set up Shift2 in the way described while<br>
MaskWords has optimal/good value.<br>
<span class=""><br>
>The value 0 feels like a bad special case because then there is only one<br>
>bit, which makes a hit more likely.<br>
><br>
>If you have a patch that can try every non zero value of shift2, would<br>
>you mind trying selecting the value that produces the most 0s and the<br>
>most 1s?<br>
><br>
>Thanks,<br>
>Rafael<br>
<br>
</span>Sure, I'll try.<br>
<span class="HOEnZb"><font color="#888888"><br>
George.<br>
</font></span></blockquote></div><br></div></div>