[lld] r319518 - Add an additional test for r319503.

[Rui Ueyama via llvm-commits]

On Mon, Dec 4, 2017 at 5:58 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Rui Ueyama <ruiu at google.com> writes:
>
> > On Mon, Dec 4, 2017 at 5:30 PM, Rafael Avila de Espindola <
> > rafael.espindola at gmail.com> wrote:
> >
> >> Rui Ueyama <ruiu at google.com> writes:
> >>
> >> > On Sat, Dec 2, 2017 at 9:09 AM, Rafael Espíndola <
> >> rafael.espindola at gmail.com
> >> >> wrote:
> >> >
> >> >> > This time I just timed the llvm tests when built with shared
> libraries
> >> >> >
> >> >> > gold:                                  138.207661064 seconds time
> >> elapsed
> >> >> > lld master:                         143.343427881 seconds time
> elapsed
> >> >> > cutting bloom filter in half: 148.267076771 seconds time elapsed
> >> >> > bloom filter of size 1:         180.053104591 seconds time elapsed
> >> >
> >> >
> >> > Did you know why gold is faster than us?
> >>
> >> Some of it is the number of buckets. Going from /4 to /2 in lld takes
> >> the test time to 142.5 seconds.
> >>
> >
> > Thanks. But that doesn't explain the difference that much though.
> >
> > I can't think of any other parameters we can tweak to optimize the
> > .gnu.hash table, so the difference might come from differences in other
> > parts of the DSOs.
>
> The gold .gnu.hash is over 2x larger than ours. It also uses a prime
> number. For libLLVMSupport for example the patched lld uses 960 buckets,
> gold uses 1031.
>

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

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

So the difference is interesting.

The 2x experiment in lld just shows that their is potential for improving
> our .gnu.hash.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171204/770fe30c/attachment.html>