From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1765 Path: news.gmane.org!not-for-mail From: musl Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso : dladdr support Date: Sun, 26 Aug 2012 02:00:31 +0200 Message-ID: <5039671F.1090308@gmail.com> References: <20120811230536.GQ27715@brightrain.aerifal.cx> <20120817053934.GS27715@brightrain.aerifal.cx> <50311776.9040802@gmail.com> <20120820020626.GD27715@brightrain.aerifal.cx> <503233A8.8000604@gmail.com> <50324A60.7040206@gmail.com> <20120823213937.GS27715@brightrain.aerifal.cx> <20120823222113.GT27715@brightrain.aerifal.cx> <50372D59.7090604@gmail.com> <20120824183850.GH27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090401080908010109070008" X-Trace: ger.gmane.org 1345939249 17972 80.91.229.3 (26 Aug 2012 00:00:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2012 00:00:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1766-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 26 02:00:50 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T5QHa-0004C5-Bq for gllmg-musl@plane.gmane.org; Sun, 26 Aug 2012 02:00:50 +0200 Original-Received: (qmail 20089 invoked by uid 550); 26 Aug 2012 00:00:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20081 invoked from network); 26 Aug 2012 00:00:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=U/jsseNhqCIggUqCJ2ZHsFx/Ju3VwiYD8gHuxPvxKKI=; b=qf5EF+yvSRedYIbdeOXAwt9n5xstD9ILur0gS6iIp+1GFwrq8PJ5/a3AiepvaaVNes dyk5eo07PJKrewGlzMl6cLVnYZkuRhRBka1K6xVDoAZVtfMFGQ5Re5Deao6/C7xsWX3u V+CnZkPVObO4L0McH3zihszyQCakZO3lI22w1l5NYim9CU4nd61/JVbaVnfPqBibBhSV RgipRmDgqFeGaFySJYZrXf30OIoCQPKgyal6nj0bWR4kwIEcmlD8yYmKKT/2/FZYbwkO HxmWFVcFRF8m+obTN1SZPKYzDiJoR4dOorEguGmjlpKSm4lA+W797Vo6xs3VBTfEOeAi c/gg== User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: <20120824183850.GH27715@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1765 Archived-At: This is a multi-part message in MIME format. --------------090401080908010109070008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------090401080908010109070008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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

--------------090401080908010109070008--