binutils/glibc .hashvals section ...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

binutils/glibc .hashvals section ...

michael meeks
Hi there,

        So - in order to speedup linking: still the major CPU hog on OO.o load,
(cf. -Bdirect patches passim) I have a simpler, perhaps less
controversial approach: storing pre-computed elf hashes in a .hashvals
section.

        This is rather nice because it turns the inner do_lookup_x loop into a
single L2 cache miss rather than 2 (.dynsym and .dynstr) - this gives
(as you might expect) a pleasant speedup. Of course, in addition since
we're accessing only a 32bit value - instead of a long (for me avg.
65byte) symbol name we also get better cache utilization.

        eg. dlopening libsvx 10x over in a loop, twice gives:

pre-compute:    989.01 ms, 983.54 ms   Avg:  986ms
normal:        1645.16 ms, 1642.92 ms  Avg: 1644ms

        ie. 40% faster. Similar numbers for VCL: ~51% faster. One would imagine
cachegrind numbers would demonstrate the improvement is ~all L2 cache
miss saving.

        Trivial patch follows; of course, since this requires glibc support one
can't be overly optimistic wrt. inclusion ;-) but surely it's only
polite to post here for discussion.

        HTH,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot

binutils-suse-hashvals.diff (6K) Download Attachment
glibc-suse-hashvals.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: binutils/glibc .hashvals section ...

H.J. Lu-27
On Wed, Jan 25, 2006 at 02:34:18PM +0000, michael meeks wrote:
> Hi there,
>
> So - in order to speedup linking: still the major CPU hog on OO.o load,
> (cf. -Bdirect patches passim) I have a simpler, perhaps less
> controversial approach: storing pre-computed elf hashes in a .hashvals
> section.
>

Have you tried other linker/glibc hash improvements suggested in the
last few weeks?


H.J.
Reply | Threaded
Open this post in threaded view
|

Re: binutils/glibc .hashvals section ...

Mike Frysinger
On Wednesday 25 January 2006 09:55, H. J. Lu wrote:

> On Wed, Jan 25, 2006 at 02:34:18PM +0000, michael meeks wrote:
> > Hi there,
> >
> > So - in order to speedup linking: still the major CPU hog on OO.o load,
> > (cf. -Bdirect patches passim) I have a simpler, perhaps less
> > controversial approach: storing pre-computed elf hashes in a .hashvals
> > section.
>
> Have you tried other linker/glibc hash improvements suggested in the
> last few weeks?

hasnt he been the one writing all of those ? ;)
-mike
Reply | Threaded
Open this post in threaded view
|

Re: binutils/glibc .hashvals section ...

Nick Clifton
In reply to this post by michael meeks
Hi Michael,

> Trivial patch follows; of course, since this requires glibc support one
> can't be overly optimistic wrt. inclusion ;-)

There is no reason why such a patch cannot be included in binutils.
People are free to modify glibc after all.

> but surely it's only polite to post here for discussion.

Well then here are some comments...

> +    case DT_SUSE_HASHVALS: name = "SUSE_HASHVALS"; break;

I assume that this feature does not have to be specific to SUSE, so I
would suggest a more generic name, eg DT_GNU_HASHVALS.

> +  if (info->hashvals)
> +    {
> +      s = bfd_make_section (abfd, ".suse.hashvals");

Similarly.  In fact if the info->hashvals field was a "const char *"
then it could be the name of the section to create.  (Not sure if this
is a good idea though).  If the name of the section is going to be fixed
however then it ought to be specified as a #defined constant in a header
file somewhere.  One that can be accessed by both binutils and glibc.
(Although you could quite reasonably point out that hard coded section
names are everywhere in the elflink.c file.  To which I would say, well
they should *all* be replaced by #define'd constants...)

Other than that though the binutils part of the patch looks fine to me.
  A few formatting tidy ups and replacements of fprintf with calls to
bfd_error_handler, but otherwise OK.

Cheers
   Nick


Reply | Threaded
Open this post in threaded view
|

Re: binutils/glibc .hashvals section ...

michael meeks
Hi Nick,

On Fri, 2006-01-27 at 17:51 +0000, Nick Clifton wrote:
> There is no reason why such a patch cannot be included in binutils.
> People are free to modify glibc after all.

        Ok; that's encouraging.

> > +    case DT_SUSE_HASHVALS: name = "SUSE_HASHVALS"; break;
>
> I assume that this feature does not have to be specific to SUSE, so I
> would suggest a more generic name, eg DT_GNU_HASHVALS.

        No of course not; however - in an effort not to tread on namespaces
other people 'own', and for which the allocation authority is unclear; I
plumped for such suse-isms. Using GNU instead would be perfect.

> If the name of the section is going to be fixed
> however then it ought to be specified as a #defined constant in a header

        Fair enough - easy to fix.

> Other than that though the binutils part of the patch looks fine to me.
>   A few formatting tidy ups and replacements of fprintf with calls to
> bfd_error_handler, but otherwise OK.

        Sure - I just got a metric bus-load of formatting / stylistic feedback
from Andreas Schwab that I'll work through too.

        Thanks,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot