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.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-suse-hashvals.diff
Type: text/x-patch
Size: 6674 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20060125/28dce55d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-suse-hashvals.diff
Type: text/x-patch
Size: 7218 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20060125/28dce55d/attachment-0001.bin>