This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Optimizing hash table lookup in symbol binding
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Mon, 18 Nov 2019 17:09:28 +0000
- Subject: Re: Optimizing hash table lookup in symbol binding
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PUO+btDWS7MX81EYxxrmY/3n3MeV3TnR/yJN9q67mbI=; b=dtnY0uQUSmoQB2dclN/iEn1SwEKoIfeD2b9FdxY8qYKyByflS0zOD8zBL3FXIib2et4aSD6AvM7WhlKaM/mlBOe/Xwtefwef82NebyGcrYJhcxm4/8jOwsgZr+oHewn7VIB5vXZZzigvXJ+UrPNa+BRcVCTlsBUFmlX3X0p2eIr3YbyDKsnFMjsNfXhovddjynNqCwb2Bp8qmYmIywhJsrxohv2L+HtbskQqzjBhSsQnQiRnyOBPTnhpcbNbrXLdk+kNluOpok6sG0dDRw6ZuC4YbrhY6L84VUUA3t8/DGcXlrg1BbhelatpMmUjiC3WoQyBKVaNK0QP6n564hXaAQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OkAR6dG0/2Z9mtsFZJD0HsMxlyrEhCiIMo8a2V35oTOET4Ec400fvY43jtmYTPJGGiKHbfXSXWGrHkKeO040nKzYvC1tPo9LNw6Z0j6L+4WAeS1bvdIW972ONaBmIA1XWilRwn/i4K0DAlrtbrKm3Us0Ud19R4e5raNYA4Sc/Mn+XYLE6N0lrD6S/Mjx6oEZ/Zz8tepuZDuihe33ZGiBi2kKflahoecfvHfum0Oe8D0wzZ5hGTjH5ZrZJq8oEknh/CHCWrdbALrVX1e1Xqj0+bXyySp6Yv9GeyeRLNxUucZk4e6IWef8gF6T7cnwVLDIrknxZ58/YGAOHcPBNxmVTA==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <87lfsd477i.fsf@oldenburg2.str.redhat.com>
On 18/11/2019 13:58, Florian Weimer wrote:
> My primary interest was the % operator because it turns out that it
> actually shows up in some profiles stressing symbol binding during
> program lookup. In most cases, however the search for the right mapping
> dominates and the preceding bitmask check fails most of the time. But
> with shallow library dependencies, we can end up in a situation where
> the division actually matters.
>
> Strategies for optimizing integer division are discussed in Hacker's
> Delight and here:
>
> <http://ridiculousfish.com/blog/posts/labor-of-division-episode-i.html>
> <http://ridiculousfish.com/blog/posts/labor-of-division-episode-iii.html>
>
> (I have written to the author to get some of the math fixed in minor
> ways, but I think the general direction is solid.)
>
> The algorithm from the first episode looks like this:
note that _itoa.c already uses something like this.
(i think the itoa code is unnecessary: there is no reason
for optimizing anything but base 10 and 16, and the compiler
can do a better job at those than trying something at runtime,
but you may look at that implementation if it's any better).