<div dir="ltr">I believe I found a bug in writeBloomFilter, and I believe that bug is the cause of the bad performance numbers lld-generated DSOs. I'll send a patch soon.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 5:43 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 11:13 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have mixed feelings about this.<br>
<br>
I can reproduce an improvement with 11:<br>
<br>
shift=6<br>
160.683939775 seconds time elapsed<br>
     ( +-  0.18% )<br>
161.236797654 seconds time elapsed<br>
     ( +-  0.30% )<br>
<br>
shift=11<br>
157.118922858 seconds time elapsed<br>
     ( +-  0.10% )<br>
158.837348716 seconds time elapsed<br>
     ( +-  0.18% )<br>
<br>
But there is still a somewhat large variation between perf runs.<br>
<br>
This also feels a bit magical, but maybe it makes perfect sense for<br>
someone familiar with hash tables and bloom filters.<br>
<br>
So I guess I am OK with the patch if it includes a comment saying that<br>
the value was found experimentally.<br>
<br>
Rui, what do you think?<br>
<br>
Cheers,<br>
Rafael<br>
<div class="m_-8044860838465045251HOEnZb"><div class="m_-8044860838465045251h5"><br>
<br>
On 15 January 2018 at 06:52, George Rimar <<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>> wrote:<br>
>>Do you know why this produces a better bloom filter?<br>
>><br>
><br>
> I think so. My thoughts are below.<br>
><br>
> Bloom filter bits are calculated as:<br>
> H1 = dl_new_hash(name);<br>
> H2 = H1 >> shift2;<br>
> BITMASK = (1 << (H1 % C)) | (1 << (H2 % C));<br>
> bloom[N] |= BITMASK;<br>
> (sample taken from <a href="https://blogs.oracle.com/ali/gnu-hash-elf-sections" rel="noreferrer" target="_blank">https://blogs.oracle.com/ali/g<wbr>nu-hash-elf-sections</a>).<br>
><br>
> As far I understand we ideally should archieve next thing when writing such filter:<br>
> (using out code now)<br>
><br>
> We apply bit 1 at first:<br>
> Val |= uint64_t(1) << (Sym.Hash % C);<br>
><br>
> Then bit 2:<br>
> Val |= uint64_t(1) << ((Sym.Hash >> getShift2()) % C);<br>
><br>
> I believe idea here is that we would like to find such shift2 constant that applying<br>
> bit 2 to Val should change Val as often as possible,<br>
> (Val | Bit1) ideally should be different from (Val | Bit1 | Bit2).<br>
> So we want to use as much different bits as possible in bloom filter overall.<br>
><br>
> That was why I tried to play with Shift2 initially.<br>
><br>
> Today I wrote simple test. It generates N symbols with random name of random length.<br>
> Then calculates Score for each Shift2 possible, where Score is amount of times where setting of Bit2<br>
> changed the bloom filter entry value. (patch is attached).<br>
> So idea was to find Shift2 so that Score is maximum.<br>
><br>
> Results looks a bit strange for me:<br>
> [Shift2] | [Score]<br>
> [0]  -> [0]<br>
> [1]  -> [8338]<br>
> [2]  -> [7762]<br>
> [3]  -> [6736]<br>
> [4]  -> [5281]<br>
> [5]  -> [3541]<br>
> [6]  -> [1995]<br>
> [7]  -> [1993]<br>
> [8]  -> [1992]<br>
> [9]  -> [1991]<br>
> [10] -> [1995]<br>
> [11] -> [1985]<br>
> [12] -> [3501]<br>
> [13] -> [5135]<br>
> [14] -> [6402]<br>
> [15] -> [7158]<br>
> [16] -> [7640]<br>
> [17] -> [7866]<br>
> [18] -> [7828]<br>
> [19] -> [7820]<br>
> [20] -> [7823]<br>
> [21] -> [7689]<br>
> [22] -> [7712]<br>
> [23] -> [7715]<br>
> [24] -> [7608]<br>
> [25] -> [7591]<br>
> [26] -> [7556]<br>
> [27] -> [7156]<br>
> [28] -> [6788]<br>
> [29] -> [6010]<br>
> [30] -> [5014]<br>
><br>
> So according to them, there is almost no difference between Shift2==6 and Shift2==11,<br>
> though Shift2==12 already shows significant difference. Best results are usually in Shift2 = [15..20] and at [1].<br>
><br>
> My patch changed value to 11. According to test above that should give no effect, because 11 != 12,<br>
> but I think that random symbol names are just to far from real live names used in LLVM,<br>
> and so probably nothing wrong with that 11 shows good results for check-llvm calls I tried.<br>
><br>
> Earlier (I mentioned at bug page) I also observer good result with Shift2=14. We probably could use it<br>
> or some other good value in [11..20] instead. I think any of them work much better than current value 6 used.<br>
><br>
> George.<br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>