This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] DT_GNU_HASH: ~ 50% dynamic linking improvement
- From: Roland McGrath <roland at redhat dot com>
- To: Paul Eggert <eggert at CS dot UCLA dot EDU>
- Cc: Jakub Jelinek <jakub at redhat dot com>, binutils at sources dot redhat dot com, libc-alpha at sources dot redhat dot com, Michael Meeks <michael dot meeks at novell dot com>
- Date: Wed, 28 Jun 2006 14:46:00 -0700 (PDT)
- Subject: Re: [PATCH] DT_GNU_HASH: ~ 50% dynamic linking improvement
> One other (perhaps dumb) question: why limit yourself to a 32-bit hash
> on machines with 64-bit addresses? Since the application area
> (linking executables) is already architecture dependent, is there a
> downside to going with 64-bit hashes on such machines?
It halves the number of table entries that can fit in the machine's cache.
To overcome the memory and cache impact of doubling the table size, there
would have to be very, very common collisions of the 32-bit hash that don't
collide with a proposed 64-bit function. Since we can select a 32-bit hash
where collisions are acceptably rare in practice, it seems unlikely that
this tradeoff would ever balance.