From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 27 20:31:31 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 7D46A106566C for ; Thu, 27 Jan 2011 20:31:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5C18FC13 for ; Thu, 27 Jan 2011 20:31:30 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0RKVQml095612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 22:31:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0RKVQQ5053485; Thu, 27 Jan 2011 22:31:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0RKVQSP053484; Thu, 27 Jan 2011 22:31:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Jan 2011 22:31:26 +0200 From: Kostik Belousov To: Mark Saad Message-ID: <20110127203126.GN2518@deviant.kiev.zoral.com.ua> References: <20110125234911.223d8f75@kan.dnsalias.net> <201101271305.21510.naylor.b.david@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lMeYSPNN/8081OSC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org 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 20:31:31 -0000 --lMeYSPNN/8081OSC Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 27, 2011 at 12:37:54PM -0500, Mark Saad wrote: > On Thu, Jan 27, 2011 at 6:05 AM, David Naylor = wrote: > > On Wednesday 26 January 2011 06:49:11 Alexander Kabaev wrote: > >> On Tue, 25 Jan 2011 21:40:42 -0500 > >> > >> Mark Saad wrote: > >> > Hello Hackers > >> > > >> > The NetBSD folks have a nice improvement with the rtld-elf subsystem, > >> > known as "Negative Symbol Cache" . > >> > > >> > http://blog.netbsd.org/tnf/entry/netbsd_runtime_linker_gains_negative > >> > > >> > =9ARoy Marples roy@ has a simple write up of the change. > >> > > >> > 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. > >> > > >> > Has anyone looked into porting the changes back to FreeBSD ? =9AThe > >> > improvement on load time for things like firefox, openoffice, and ja= va > >> > is huge on NetBSD. It looks like this change could improve load times > >> > on FreeBSD in the same ways. > >> > >> 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 > >> > >> 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. = =9AI > > timed the boot-time to when KDE launches autostart programs and once all > > programs have loaded (I run a few extra programs, such as amarok). =9AT= he latter > > measure requires human action thus it has extra, human, variance in its > > measure. > > > > I tried an older version of rtld (about 2 months old), current version = of rtld > > and the new (patched) rtld. =9AI ran each test three times. =9AThere wa= s little > > variance in the tests and I am confident that there is no difference be= tween > > the different rtld versions and my boot-time. > > > > Here is a summary of my boot times (in seconds). =9AFirst measure is wh= en KDE > > autostarts programs, the latter is when I determined when all programs = had > > launched. > > rtld-old: 69 96 > > rtld: =9A =9A 69 94 > > rtld-new: 69 94 > > > > Please note that kernel boot time is approximately 10 seconds and kdm is > > delayed by about 10 seconds thus 20 seconds can be removed from above n= umbers > > to determine non-kernel boot wall-time. > > > > I would like to add that the blog entry claims a substantial improvemen= t for > > some use cases. =9AIs it not worth to optimism these fringe cases as on= e mans > > fringe case is another mans normal case (or woman as one prefers)? > > >=20 >=20 > So I figured out how to properly fit my foot in my mouth and set out > to retesting this on netbsd. > Turns out that in most cases the speed up is not as dramatic. >=20 > Firefox 3.6.16 on amd64 >=20 > old ld.elf_so: 4.07 seconds > new ld.elf_so: 3.89 seconds >=20 > Openoffice 3.1 on amd64 >=20 > old ld.elf_so: 2.67 seconds > new ld.elf_so: 2.60 seconds >=20 > I am slightly perturbed that I can start openoffice faster then I can > start firefox, oh well. Can you, please, satisfy my curiousity ? How did you fixated the moment of finishing the startup of interactive applications like ff or oo ? --lMeYSPNN/8081OSC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1B1h4ACgkQC3+MBN1Mb4hnkACgzH58bv40XmpiNaeSNNNPLKt0 cqMAoK64gtTp8y/p/rP74lIIWhl51I7l =0ctD -----END PGP SIGNATURE----- --lMeYSPNN/8081OSC--