Date: Wed, 26 Nov 2003 12:51:38 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: kutulu@kutulu.org Cc: freebsd-current@freebsd.org Subject: Re: 40% slowdown with dynamic /bin/sh Message-ID: <20031126.125138.133913249.imp@bsdimp.com> In-Reply-To: <20031126144357.GK15294@wombat.localnet> References: <20031126052320.GH15294@wombat.localnet> <p06002014bbea2b21766b@[128.113.24.47]> <20031126144357.GK15294@wombat.localnet>
index | next in thread | previous in thread | raw e-mail
In message: <20031126144357.GK15294@wombat.localnet>
Michael Edenfield <kutulu@kutulu.org> writes:
: time make -j 4 buildworld
Hmmm, more jobs.
: They were on a single CPU Athlon 500 with 320MB of RAM.
320MB is not enough RAM not to swap.
I did some preliminary testing last night (which I lost due to a
crash) that showed that a simple 'make buildworld' slowed down 1-2%
depending on how many times I ran them.
However, make -s buildworld (with or without -j 4 on my dual athlon)
was faster than a normal buildworld, but the dynamic /bin/sh was more
like 5-7% slower. The difference here is that there are fewer context
switches (and I guess less chance for parallelization).
In all make buildworld, the number of page faults was 10x for the
dynamic case than for the static case.
However, having said that, I think everybody realizes the following:
1) Dynamic linking is slower.
2) Speed improvements in this area are possible, as
demonstrated by other projects.
3) PIC code is slower than non-PIC code, in general, and also
gcc runs about 5-10% slower depending on if you are running
out of a shared library or a static one. shared libraries
must use PIC code (at this time).
4) People like to complain.
Warner
P.S. One interesting note: /bin/sh when linked statically with
libedit and libncurses but dynamically with libc runs about 10% slower
for my /usr/bin/true/true tests than when all three are dynamically
linked. So it seems that not all dynamic linking is bad for
performance.
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031126.125138.133913249.imp>