From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 27 11:33:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E0E5106564A for ; Thu, 27 Jan 2011 11:33:41 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 305788FC12 for ; Thu, 27 Jan 2011 11:33:40 +0000 (UTC) Received: by gxk8 with SMTP id 8so592623gxk.13 for ; Thu, 27 Jan 2011 03:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=mU2RAZbA+mM21PIN7uIW/TLpfz1/kh5vghcldEj5ZCA=; b=UPuOlVog/8nFJr36jJ9R+USMWi1KSSAtEAzqnuANYgY8RURBHr9zt/T4nIoortk8Ce ZI5NP/8pgesgtSU6UXokG10N/8XfeEGYrRwz7E+Nk1FpXoSSSDUGH7mipNAweMdBvqzc BHljy58fItt7j93LPSuj2YMgTS8UAiNuSgwZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=MKtyfHbj+qWyKAs65pyU57ykFNfKlq4ExSy/q+lGU3aTTFUUM7vr08i2WtTAc9EDR4 9Ov2oajlddyodOgAE6Yo5p4nq/UfG+cl0o9jnu+2a4vl8CDA+pEGKqHm7X/jxYfs9+Ud V4L87HV4raS4Nt/1D4HRNHtSy+qmCROFMvjuw= Received: by 10.90.232.6 with SMTP id e6mr2869219agh.52.1296126334655; Thu, 27 Jan 2011 03:05:34 -0800 (PST) Received: from dragon.dg (41-132-211-236.dsl.mweb.co.za [41.132.211.236]) by mx.google.com with ESMTPS id b19sm20313583ana.27.2011.01.27.03.05.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 03:05:33 -0800 (PST) From: David Naylor To: Alexander Kabaev Date: Thu, 27 Jan 2011 13:05:17 +0200 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.4; amd64; ; ) References: <20110125234911.223d8f75@kan.dnsalias.net> In-Reply-To: <20110125234911.223d8f75@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1565754.HW3NjhCSA8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101271305.21510.naylor.b.david@gmail.com> Cc: freebsd-hackers@freebsd.org, Mark Saad Subject: Re: rtld optimizations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 11:33:41 -0000 --nextPart1565754.HW3NjhCSA8 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday 26 January 2011 06:49:11 Alexander Kabaev wrote: > On Tue, 25 Jan 2011 21:40:42 -0500 >=20 > Mark Saad wrote: > > Hello Hackers > >=20 > > The NetBSD folks have a nice improvement with the rtld-elf subsystem, > > known as "Negative Symbol Cache" . > >=20 > > http://blog.netbsd.org/tnf/entry/netbsd_runtime_linker_gains_negative > >=20 > > Roy Marples roy@ has a simple write up of the change. > >=20 > > I took the basic idea from FreeBSD, but improved the performance > > drastically. Basically, the huge win is by caching both breadth and > > depth of the needed/weak symbol lookup. > > Easiest to think of a,b,c,d as a matrix and FreeBSD just cache a row > > where we cache both rows and columns. > >=20 > > Has anyone looked into porting the changes back to FreeBSD ? The > > improvement on load time for things like firefox, openoffice, and java > > is huge on NetBSD. It looks like this change could improve load times > > on FreeBSD in the same ways. >=20 > This is a second time someone posts this to public mailing list and > curiously enough is a second time it suggested that someone else is to > do the investigation. From the quick look, the commit in question is > more or less a direct rip-off of Donelists we had for ages and as > such is completely over-hyped. The only extra quirk that said commit > does is an optimization of a dlsym() call, which is hardly ever in > critical performance path. Said optimization is trivial and easy to > try. Here you have it: > http://people.freebsd.org/~kan/rtld-symlook-depth.diff >=20 > Since it only applies to dlsym, it only affects programs that are heavy > plugin users, which I suppose is the category OpenOffice and firefox > both fall into. Care to do some benchmarks with and without the > patch and report the results? I frankly doubt that you'll see any > noticeable difference compared to our stock rtld's performance. I benchmarked the impact said patch has on the boot-time of my system. I=20 timed the boot-time to when KDE launches autostart programs and once all=20 programs have loaded (I run a few extra programs, such as amarok). The lat= ter=20 measure requires human action thus it has extra, human, variance in its=20 measure. =20 I tried an older version of rtld (about 2 months old), current version of r= tld=20 and the new (patched) rtld. I ran each test three times. There was little= =20 variance in the tests and I am confident that there is no difference betwee= n=20 the different rtld versions and my boot-time. =20 Here is a summary of my boot times (in seconds). First measure is when KDE= =20 autostarts programs, the latter is when I determined when all programs had= =20 launched. =20 rtld-old: 69 96 rtld: 69 94 rtld-new: 69 94 Please note that kernel boot time is approximately 10 seconds and kdm is=20 delayed by about 10 seconds thus 20 seconds can be removed from above numbe= rs=20 to determine non-kernel boot wall-time. =20 I would like to add that the blog entry claims a substantial improvement fo= r=20 some use cases. Is it not worth to optimise these fringe cases as one mans= =20 fringe case is another mans normal case (or woman as one prefers)? =20 --nextPart1565754.HW3NjhCSA8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEABECAAYFAk1BUXEACgkQUaaFgP9pFrJbSgCggF7p2zHoGI7vTAYqTrfeIb6r 37oAnR4OPPQZ+uLWBMZx1tpzoDi9Vfkn =NgxZ -----END PGP SIGNATURE----- --nextPart1565754.HW3NjhCSA8--