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
> 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++ -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

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.


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.
	- Richard Brautigan

More information about the freebsd-sparc64 mailing list