On 24/08/2012 20:38, Rich Felker wrote:

On Fri, Aug 24, 2012 at 09:29:29AM +0200, musl wrote:

I tested it and it works well.

Is there anything I changed that you think might be better done a
different way?

My tests are based on small libs (with a small set of shared symbols).
I mixed libs with gnu hash and sysv hash.
Tried to resolve symbols via dlsym.

Have you tested it on big libraries ?

No, just very minimal testing.

Do you want me to do some specific tests ?

Actually, the main thing I'm interested in is whether the bloom filter
is ever beneficial. I took it out trying to streamline the code and
shaved about 8% off the lookup time for symbols in the main program,
but I didn't investigate how the change affects symbols not found in
the first file searched. Would you be interested in running some tests
to determine if it might be useful to try adding it back?

I tried the perf application ( https://perf.wiki.kernel.org/index.php/Tutorial)
with this command : 'perf stat -e instructions:u ./gnuhash main' (gives number of instructions executed in user space by gnuhash program).

Here are the results :

With bloom filter :

577 0x80483c4

Performance counter stats for './gnuhash main':

            31 895 instructions:u            #    0,00 insns per cycle

       0,000792737 seconds time elapsed

Without bloom filter :

588 0x80483c4

Performance counter stats for './gnuhash main':

            31 195 instructions:u            #    0,00 insns per cycle

       0,000802368 seconds time elapsed

As you can see there are less instructions executed in the version without bloom filter but it's slower.
I guess this difference come from the symbol resolution during the relocation process.

Since it seems to be working/non-broken right now, I'll probably go
ahead and commit soon unless you find a major problem I've overlooked.
Then we can work on improving it once it's in the repo.

Rich