<div dir="ltr"><div>You forgot to attach your patches?</div><div><br></div><div>On Mon, Jan 22, 2018 at 4:05 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>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>Patches are in attachment.<br>
Results for llvm-check for me are:<br>
LLD head rev (r323036): 410.27s, 410.58s.<br>
most_1.patch: 400.71s, 400.29s.<br>
most_0.patch: 418.02s, 417.11s.<br>
<br>
Results seems shows that the more filter is filled is better for this particular testcase.<br>
<br>
So to summarize my theory in short:<br>
I guess that happens because symbol names that loader tries to lookup has the similar<br>
nature to those we use for building .gnu_hash. And so during lookup it looks has more chance<br>
to avoid false positive, since our filter size is already large (and so has enough zeroes anyways),<br>
and tweaking Shift2 to produce most 1s probably better than have less bits set in a filter entry word.<br>
(when bits are more localized, we looks have more chance to select the same bits during lookup and have<br>
false positive).<br></blockquote><div><br></div><div>I do not understand the theory. Adding 1 bits to a bloom filter only increases the chance of false positives, no? A bloom filter that has more 1 bits has higher probability of false positives.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess if we link some application, it is fine to optimize .gnu_hash table for some symbols and assume<br>
that nature of symbol names will be similar with names that loader will try to lookup. Probably.<br>
<br>
I do not know if hash function mentioned in this thread returns evenly distributed hash values.<br>
Test that used random names showed that Shift2 choice affects on how much bits will be set in bloom filter.<br>
I would expect no difference for different Shift2 if values would be evenly distributed.<br>
<br>
"most_0", "most_1" and "random names" tests looks shows that filter density depends on Shift2 value.<br>
And filter density for currnt bloom filter size chosen looks has correlation with lookup speed in unexpected way.<br>
<span class="HOEnZb"><font color="#888888"><br>
George.</font></span></blockquote></div><br></div></div>