From: Michael Meeks <michael.meeks@novell.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: binutils@sources.redhat.com, libc-alpha@sources.redhat.com,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: DT_GNU_HASH: reducing working set ...
Date: Mon, 03 Jul 2006 18:18:00 -0000 [thread overview]
Message-ID: <1151950882.17892.146.camel@t60p.site> (raw)
In-Reply-To: <20060703155925.GE3823@sunsite.mff.cuni.cz>
On Mon, 2006-07-03 at 17:59 +0200, Jakub Jelinek wrote:
> Ok, good we are on the same page ;)
:-)
> Djamel privately mentioned to me today that indeed if we require
> nbuckets > 1 for valid .gnu.hash sections, we can get the chain
> termination bit for free, i.e. not causing any extra collisions.
> That's because if nbuckets > 1, then (hash+1) % nbuckets != hash % nbuckets,
> so the bottom-most bit is effectively encoded in the bucket.
Ah - that's a neat trick: nice [ not that it isn't worth the single bit
anyway of course, as per convoluted calculations ;-]
> We have 2 options, either we create a 1:1 correspondence between the chain
> position and .dynsym index (and perhaps sort the UNDEF symbols high, so that
> we can trim the end of the .gnu.hash section), or we can store some addend
> into the second word of .gnu.hash (before the buckets array).
The addend sounds nice.
Of course - it depends on how hard to calculate the hash function is:
we could of course use a rather stronger / slower hash: and simply store
the value for all symbols [ regardless of def/undef etc. ] in the .chain
- and instead of calculating, look them up. [ Of course to calculate the
string hash we have to take a .dynstr cache miss in the 1st place so -
perhaps it's worthwhile ? ].
Of course, if we do that, then it does in fact make sense to have the
-Bdirect indexes next to the undef symbols, so - OTOH - perhaps that
sort of thing does belong in another section;
> ELF requires that the STB_LOCAL symbols are at the beginning, not end of
> the .dynsym section.
Yep - I fell over that :-)
> The UNDEF symbols can of course be anywhere (after
> the STB_LOCAL symbols). On most of the arches there are only a few
> STB_LOCAL symbols (< ~20), but on e.g. ia64 there are really many
> (e.g. ia64 glibc has ~ 420 such symbols, all caused by relocations).
> So, perhaps using the addend would be best.
That's interesting; I have an architecturally blinkered view.
> I will rework the patch now.
Thanks,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
next prev parent reply other threads:[~2006-07-03 18:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 17:21 [PATCH] DT_GNU_HASH: ~ 50% dynamic linking improvement Jakub Jelinek
2006-06-28 19:10 ` Paul Eggert
2006-06-28 20:25 ` Roland McGrath
2006-06-28 21:40 ` Jakub Jelinek
2006-06-28 21:46 ` Paul Eggert
2006-06-28 21:49 ` Roland McGrath
2006-06-29 0:35 ` Ulrich Drepper
2006-06-29 19:39 ` Michael Meeks
2006-06-29 21:52 ` Jakub Jelinek
2006-07-03 15:12 ` DT_GNU_HASH: reducing working set Michael Meeks
2006-07-03 15:59 ` Jakub Jelinek
2006-07-03 18:18 ` Michael Meeks [this message]
2006-07-03 21:05 ` [PATCH] DT_GNU_HASH: reducing working set ... (take 2) Jakub Jelinek
2006-06-30 23:55 ` DT_GNU_HASH: ~ 50% dynamic linking improvement Ulrich Drepper
2006-07-03 9:26 ` Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1151950882.17892.146.camel@t60p.site \
--to=michael.meeks@novell.com \
--cc=binutils@sources.redhat.com \
--cc=drepper@redhat.com \
--cc=jakub@redhat.com \
--cc=libc-alpha@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).