ponderous 'make world' times post GCC 3.3...
Tillman
tillman at seekingfire.com
Tue Aug 12 20:33:58 PDT 2003
On Mon, Aug 11, 2003 at 11:51:00AM -0400, Garance A Drosihn wrote:
> At 1:40 AM -0700 8/9/03, Kris Kennaway wrote:
> >On Sat, Aug 09, 2003, Garance A Drosihn wrote:
> >
> >> So, apparently the problem is something a bit more subtle than
> >> just gcc 3.3 being slower to compile than gcc 3.2. Apparently
> >> the August 9th system is a lot slower at *running* than the
> >> early system. Do we have some other benchmarks we could run?
> >
> >This suggests that something might have been pessimized with
> >the gcc 3.3 code generation on sparc.
>
> Well, I'm thinking that maybe we're blaming the wrong thing
> for this slowdown. I have the results for a few more builds:
>
> realtime user sys
> ---------- ------------- ------------
> build 1: 347m 33.407s 283m 0.162s 53m 45.805s
> build 2: 387m 4.205s 315m 25.441s 59m 44.648s
> build 3: 1238m 11.386s 1064m 31.148s 136m 54.366s
> build 4: 384m 30.479s 312m 54.407s 59m 7.338s
<snip>
> I don't know where the slowdown is occurring. Obviously it is
> something which clobbers a buildworld, so maybe disk access or
> something like that (I have enough real memory that my system
> never pages). That's why I was wondering if there were some
> other benchmarks we could run. The only thing that I really do
> with my freebsd/sparc machine is buildworld's of freebsd/sparc,
> so there is nothing else where I would notice a major slowdown
> (even if it were occurring).
Disk access could indeed be a problem. Here's the build times and
bonnie++ results on the original EIDE drive in my Ultra 5:
time make buildworld:
real 1485m0.214s
user 915m40.322s
sys 98m56.775s
time make buildkernel:
real 487m44.136s
user 400m55.723s
sys 24m34.634s
bonnie++:
# bonnie++ -d /usr/scratch/ -m caliban -u 0
Version 1.93c ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
caliban 300M 8 92 1999 10 924 5 15 92 1887 6 72.4 21
Latency 2260ms 519ms 2964ms 1117ms 161ms 3688ms
Version 1.93c ------Sequential Create------ --------Random Create--------
caliban -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 856 68 2968 89 2478 94 811 60 2817 84 2770 94
Latency 1589ms 250ms 3365us 1674ms 477ms 10394us
1.93c,1.93c,caliban,1,1060744776,300M,,8,92,1999,10,924,5,15,92,1887,6,72.4,21,16,,,,,856,68,2968,89,2478,94,811,60,2817,84,2770,94,2260ms,519ms,2964ms,1117ms,161ms,3688ms,1589ms,250ms,3365us,1674ms,477ms,10394us
That's a slow disk. I have a 25Mhz decstation that outperforms the Ultra
5 on disk I/O. Unfortunately, I don't have drive timings from when the
buildworlds where faster to compare, so this could be a red herring :-(
Drive details:
# dmesg | grep ad0
ad0: 8223MB <ST38410A> [16708/16/63] at ata2-master WDMA2
> On build #3 I noticed that 'top' constantly reported the CPU
> was 0.0% idle. Unfortunately I couldn't check that for build #4,
> because I didn't have a 'top' which matched the running kernel...
I also have the the 0% idle top during buildworld, even though I'm not
using -jX. It seems odd to me - with disk I/O that slow, I would think
that the CPU should be partially/occasionally idle during a buildworld.
-T
--
1. Get enough food to eat, and eat it.
2. Find a place to sleep where it is quiet, and sleep there.
3. Reduce intellectual and emotional noise until you arrive at the silence of
yourself, and listen to it.
4.
- Richard Brautigan
More information about the freebsd-sparc64
mailing list