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

[Rui Ueyama via llvm-commits]

You forgot to attach your patches?

On Mon, Jan 22, 2018 at 4:05 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >If you have a patch that can try every non zero value of shift2, would
> >you mind trying selecting the value that produces the most 0s and the
> >most 1s?
> >
> >Thanks,
> >Rafael
>
> Patches are in attachment.
> Results for llvm-check for me are:
> LLD head rev (r323036): 410.27s, 410.58s.
> most_1.patch: 400.71s, 400.29s.
> most_0.patch: 418.02s, 417.11s.
>
> Results seems shows that the more filter is filled is better for this
> particular testcase.
>
> So to summarize my theory in short:
> I guess that happens because symbol names that loader tries to lookup has
> the similar
> nature to those we use for building .gnu_hash. And so during lookup it
> looks has more chance
> to avoid false positive, since our filter size is already large (and so
> has enough zeroes anyways),
> and tweaking Shift2 to produce most 1s probably better than have less bits
> set in a filter entry word.
> (when bits are more localized, we looks have more chance to select the
> same bits during lookup and have
> false positive).
>

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 guess if we link some application, it is fine to optimize .gnu_hash table
> for some symbols and assume
> that nature of symbol names will be similar with names that loader will
> try to lookup. Probably.
>
> I do not know if hash function mentioned in this thread returns evenly
> distributed hash values.
> Test that used random names showed that Shift2 choice affects on how much
> bits will be set in bloom filter.
> I would expect no difference for different Shift2 if values would be
> evenly distributed.
>
> "most_0", "most_1" and "random names" tests looks shows that filter
> density depends on Shift2 value.
> And filter density for currnt bloom filter size chosen looks has
> correlation with lookup speed in unexpected way.
>
> George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180122/2b3f33cb/attachment.html>