In message: <[EMAIL PROTECTED]>
Michael Edenfield <[EMAIL PROTECTED]> 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.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
