Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jan 2011 22:59:07 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Devin Teske <dteske@vicor.com>
Cc:        freebsd-hackers@freebsd.org, Mark Saad <nonesuch@longcount.org>
Subject:   Re: rtld optimizations
Message-ID:  <20110127205907.GP2518@deviant.kiev.zoral.com.ua>
In-Reply-To: <1296161448.20060.40.camel@dt.vicor.com>
References:  <AANLkTikwHteyqMfMpy_B-AxQ5ZQ_Z3RKhkNpGN23fXtX@mail.gmail.com> <20110125234911.223d8f75@kan.dnsalias.net> <201101271305.21510.naylor.b.david@gmail.com> <AANLkTinkhfso3iRR4pERxhf=%2BnCqy2YDigzgyfNVtnaJ@mail.gmail.com> <20110127203126.GN2518@deviant.kiev.zoral.com.ua> <1296161448.20060.40.camel@dt.vicor.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--lvRZZFMRNRLg22E3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 27, 2011 at 08:50:48PM +0000, Devin Teske wrote:
> On Thu, 2011-01-27 at 22:31 +0200, Kostik Belousov wrote:
>=20
> > On Thu, Jan 27, 2011 at 12:37:54PM -0500, Mark Saad wrote:
> > > On Thu, Jan 27, 2011 at 6:05 AM, David Naylor <naylor.b.david@gmail.c=
om> wrote:
> > > > On Wednesday 26 January 2011 06:49:11 Alexander Kabaev wrote:
> > > >> On Tue, 25 Jan 2011 21:40:42 -0500
> > > >>
> > > >> Mark Saad <nonesuch@longcount.org> wrote:
> > > >> > Hello Hackers
> > > >> >
> > > >> > The NetBSD folks have a nice improvement with the rtld-elf subsy=
stem,
> > > >> > known as "Negative Symbol Cache" .
> > > >> >
> > > >> > http://blog.netbsd.org/tnf/entry/netbsd_runtime_linker_gains_neg=
ative
> > > >> >
> > > >> >  Roy 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 ?  The
> > > >> > improvement on load time for things like firefox, openoffice, an=
d java
> > > >> > 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 i=
s 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 comm=
it
> > > >> 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 firef=
ox
> > > >> 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 syst=
em.  I
> > > > timed the boot-time to when KDE launches autostart programs and onc=
e all
> > > > programs have loaded (I run a few extra programs, such as amarok). =
 The 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 vers=
ion of rtld
> > > > and the new (patched) rtld.  I ran each test three times.  There wa=
s little
> > > > variance in the tests and I am confident that there is no differenc=
e between
> > > > the different rtld versions and my boot-time.
> > > >
> > > > Here is a summary of my boot times (in seconds).  First measure is =
when KDE
> > > > autostarts programs, the latter is when I determined when all progr=
ams had
> > > > launched.
> > > > rtld-old: 69 96
> > > > rtld:     69 94
> > > > rtld-new: 69 94
> > > >
> > > > Please note that kernel boot time is approximately 10 seconds and k=
dm is
> > > > delayed by about 10 seconds thus 20 seconds can be removed from abo=
ve numbers
> > > > to determine non-kernel boot wall-time.
> > > >
> > > > I would like to add that the blog entry claims a substantial improv=
ement for
> > > > some use cases.  Is it not worth to optimism these fringe cases as =
one 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.
> >=20
> > Can you, please, satisfy my curiousity ? How did you fixated the moment
> > of finishing the startup of interactive applications like ff or oo ?
>=20
>=20
> Probably did something like this:
>=20
>     time sh -c '( firefox & ); sleep 10000000'
>=20
> and then pressed Ctrl-C when he felt that firefox was finished loading.
> The moment Ctrl-C is pressed, time(1) shows how long it ran up until you
> pressed Ctrl-C.
> NOTE: Pressing Ctrl-C will not terminate the firefox instance.

You cannot have 1/100 of seconds precision with this method.
This is why I am asking, seeing < 0.1 seconds difference.
Not to mention some methodical questions, like whether the caches were
warmed before the measurement by several runs before the actual
test.

--lvRZZFMRNRLg22E3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk1B3JoACgkQC3+MBN1Mb4hgKgCfd3W6bVufyXRpyxcBhCrfjLu9
B2oAoOsQrBPZ2G5Q/DhoqXyisgSkvRL5
=NGuJ
-----END PGP SIGNATURE-----

--lvRZZFMRNRLg22E3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110127205907.GP2518>