ponderous 'make world' times post GCC 3.3...

Garance A Drosihn drosih at rpi.edu
Mon Aug 11 08:51:05 PDT 2003

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

build 1 is the cvsup'ed from July 6th, being built on
         top of a world from June 6th.
build 2 is the cvsup'ed source from August 7th, built
         on top of the world from June 6th (apparently I
         never installed the buildworld from July 6th).
build 3 is the exact same source as build #2, built on
         the world that was installed by build 2.
build 4 is where I took the kernel from build #1 (which
         was sitting in /boot/kernel.old), and booted off
         of that.  So, the system is running the kernel
         from June 6th, but the entire userland is from
         August 7th.  This means it starts out with
         gcc (GCC) 3.3.1 [FreeBSD] 20030711 (prerelease).

So, the slowdown is completely in the kernel.  Either there
was some change made to the kernel-sources which has caused
the slowdown, or there is something about gcc 3.3.1's code
generation such that we end up with a horrendously slower
kernel.  But it isn't gcc 3.3.1 *itself* which is that much
slower at compiling.

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).

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

Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu

More information about the freebsd-sparc64 mailing list