[PATCH] D41993: [ELF] - Change shift2 constant of GNU_HASH from 6->11.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 23 16:16:05 PST 2018


On Mon, Jan 22, 2018 at 11:53 PM, George Rimar <grimar at accesssoftek.com>
wrote:

> >You forgot to attach your patches?
>
> Right, sorry. Attached now.
>
> >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.
>
> I think answer is both "yes" and "no". Otherwise testing results would
> probably be different.
>
> I think it is both increases chance of false positive because of natural
> reasons you mentioned,
> but looks at the same time it increases chance to select different bits
> during lookup,
> so gives greater chance to select zero instead of existent 1 for symbol
> that is not in table.
> Balance seems to be somewhere in between.​
>
> Probably best way to check/prove it is to benchmark to count false
> positives during lookup somehow.
> I can think of built-in LLD benchmark atm. It could take existent symbols,
> modify their names slightly and
> perform lookup.
>

That's a hypothesis and not a proved theory nor even an observation. I'm
sorry but I can't LGTM a performance improvement patch that were not backed
by a reasonable theory, as it would create a cargo cult.

I spend a few hours to find out why the time to resolve dynamic symbols
differs depending on Shift2. It looks like hash values are fairly nicely
distributed, and I couldn't figure out the reason. Unfortunately I don't
have enough time to investigate it further at the moment. Maybe we both
spent too much time on this.

You could spend more time on this to figure it out, but I guess that this
is not the highest priority thing in your todo list. If you want to work on
this, you want to take a look at the dynamic linker and trace it to
understand what's going on there. But again I'm not sure if you want to do
that now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180123/ee95613e/attachment.html>


More information about the llvm-commits mailing list