<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 4, 2017 at 5:58 PM, Rafael Avila de Espindola <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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> On Mon, Dec 4, 2017 at 5:30 PM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>> Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
>><br>
>> > On Sat, Dec 2, 2017 at 9:09 AM, Rafael Espíndola <<br>
>> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a><br>
>> >> wrote:<br>
>> ><br>
>> >> > This time I just timed the llvm tests when built with shared libraries<br>
>> >> ><br>
>> >> > gold:                                  138.207661064 seconds time<br>
>> elapsed<br>
>> >> > lld master:                         143.343427881 seconds time elapsed<br>
>> >> > cutting bloom filter in half: 148.267076771 seconds time elapsed<br>
>> >> > bloom filter of size 1:         180.053104591 seconds time elapsed<br>
>> ><br>
>> ><br>
>> > Did you know why gold is faster than us?<br>
>><br>
>> Some of it is the number of buckets. Going from /4 to /2 in lld takes<br>
>> the test time to 142.5 seconds.<br>
>><br>
><br>
> Thanks. But that doesn't explain the difference that much though.<br>
><br>
> I can't think of any other parameters we can tweak to optimize the<br>
> .gnu.hash table, so the difference might come from differences in other<br>
> parts of the DSOs.<br>
<br>
</span>The gold .gnu.hash is over 2x larger than ours. It also uses a prime<br>
number. For libLLVMSupport for example the patched lld uses 960 buckets,<br>
gold uses 1031.<br></blockquote><div><br></div><div>960 and 1031 aren't that different, and not using the prime number shouldn't make change as long as the lengths of hash chains are not too biased (which I believe true).</div><div><br></div><div>I took a quick look at `do_lookup_x` function in elf/dl-lookup.c in glibc, and looks like the penalty of hash collision is pretty low there (we just need to skip a uint32_t value for each collision.)<br></div><div><br></div><div>So the difference is interesting.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The 2x experiment in lld just shows that their is potential for improving<br>
our .gnu.hash.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>