public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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


  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).