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