[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jun 2015 01:39:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/5] dynlink.c: use bloom filter in gnu hash lookup
On Wed, Jun 24, 2015 at 02:24:51AM +0300, Alexander Monakov wrote:
> Introduce gnu_lookup_filtered and use it to speed up symbol lookups in
> find_sym (do_dlsym is left as is, based on an expectation that frequently
> dlsym queries will use a dlopen handle rather than RTLD_NEXT or RTLD_DEFAULT,
> and will not need to look at more than one DSO). The size of the bloom filter
> table minus 1, ghashmask, is stored in the dso struct together with the
> hashtable pointer to reduce pointer chasing on the hot path.
> ---
> src/ldso/dynlink.c | 30 ++++++++++++++++++++++++++----
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c
> index b77c6f6..fa91b39 100644
> --- a/src/ldso/dynlink.c
> +++ b/src/ldso/dynlink.c
> @@ -54,6 +54,7 @@ struct dso {
> Sym *syms;
> uint32_t *hashtab;
> uint32_t *ghashtab;
> + uint32_t ghashmask;
> int16_t *versym;
> char *strings;
> unsigned char *map;
> @@ -200,6 +201,19 @@ static Sym *gnu_lookup(const char *s, uint32_t h1, struct dso *dso)
> return 0;
> }
>
> +static Sym *gnu_lookup_filtered(const char *s, uint32_t h1, struct dso *dso, uint32_t fofs, size_t fmask)
> +{
> + uint32_t *hashtab = dso->ghashtab;
> + size_t *bloomwords = hashtab+4;
> + size_t f = bloomwords[fofs & dso->ghashmask];
Is this measurably faster than fofs & hashtab[2]-1 ?
If suspect not, in which case it seems desirable not to increase the
size of struct dso. If it is worthwhile, at least don't sandwich a
uint32_t between two pointers where it might incur another 32 bits of
padding.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
