Bootstrap times on mainline are getting worse

Bootstrap times on mainline are getting worse

[Diego Novillo]

http://people.redhat.com/dnovillo/spec95/gcc/gcc-stats.html

Bootstrap times have been creeping up lately.  Today's mainline
is 10% slower to bootstrap C and Fortran than a month ago.
The biggest increase in bootstrap times seems to have come after
Oct05.


Diego.

Re: Bootstrap times on mainline are getting worse

[Andreas Schwab]

Diego Novillo <dnovillo@redhat.com> writes:

|> http://people.redhat.com/dnovillo/spec95/gcc/gcc-stats.html
|> 
|> Bootstrap times have been creeping up lately.  Today's mainline
|> is 10% slower to bootstrap C and Fortran than a month ago.
|> The biggest increase in bootstrap times seems to have come after
|> Oct05.

Not so on ia64.  In fact, bootstrap times have decreased here.

http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00043.html
http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00549.html

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bootstrap times on mainline are getting worse

[Michael Ritzert]

I've been collecting bootstrap times for gcc HEAD on i386-unknown-freebsd4.5 
on an Athlon 1000 for 3 months now. You can find the plot a 
http://www.globe-tec.de/~ritzert/gcc.png . The first plot is the user time as 
reported by 'make bootstrap', excluding 'make gnatlib_and_tools'. The second 
dataset is the time it takes to compile STLport 4.5.3 on the same machine. I 
do also have the object sizes recorded in case somebody cares.

As a short summary, bootstrap time has gone up from around 4150 seconds on 
05/07 to ca. 4700s today.
The compile time for STLport is about the same as at the beginning of July, 
but went up and down 10% respectively in between (the periods without crosses 
mark failures to build STLport, the current one being caused by 
http://gcc.gnu.org/ml/gcc/2002-10/msg00846.html ).

Michael

Re: Bootstrap times on mainline are getting worse

[Kaveh R. Ghazi]

IMHO measuring total bootstrap time of changing snapshots is not a
very accurate gauge of GCC's compile-time speed because the amount and
nature of the source code is constantly changing.  What you should
instead measure is a consistent set of (perhaps GCC but perhaps other)
source code compiled with different versions of GCC CVS snapshots.
I.e. do a "make all" rather than "make bootstrap" with different
values of $CC.

That would be a proper "apples to apples" comparison upon which you
could draw conclusions about whether compile-time speed was slowing
down.  I'm not saying it isn't slowing down, but that the figures
posted so far aren't actually measuring that AFAICT.

		--Kaveh

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Bootstrap times on mainline are getting worse

[Diego Novillo]

On Thu, 17 Oct 2002, Kaveh R. Ghazi wrote:

> That would be a proper "apples to apples" comparison upon which you
> could draw conclusions about whether compile-time speed was slowing
> down.  I'm not saying it isn't slowing down, but that the figures
> posted so far aren't actually measuring that AFAICT.
> 
Very good point.  I should've thought of that before.  We could
analyze SPEC build times instead.

http://people.redhat.com/dnovillo/spec95/gcc/global-build-secs_elapsed.html

For CINT95 base, we have a 6% increase in build times since
Sep19.  There is a noticeable jump around Oct06.


Diego.

Re: Bootstrap times on mainline are getting worse

[Kaveh R. Ghazi]

> From: Diego Novillo <dnovillo@redhat.com>
> 
> On Thu, 17 Oct 2002, Kaveh R. Ghazi wrote:
> 
> > That would be a proper "apples to apples" comparison upon which you
> > could draw conclusions about whether compile-time speed was slowing
> > down.  I'm not saying it isn't slowing down, but that the figures
> > posted so far aren't actually measuring that AFAICT.
> 
> Very good point.  I should've thought of that before.  We could
> analyze SPEC build times instead.
> 
> http://people.redhat.com/dnovillo/spec95/gcc/global-build-secs_elapsed.html
> 
> For CINT95 base, we have a 6% increase in build times since
> Sep19.  There is a noticeable jump around Oct06.
> Diego.

Ok that settles it, thanks for checking.

Since it's so sharp, now we just need someone to binary search Oct 5-7
and figure out which patch did it.

Care to take a stab?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Bootstrap times on mainline are getting worse

[Diego Novillo]

On Fri, 18 Oct 2002, Kaveh R. Ghazi wrote:

> Care to take a stab?
> 
Heh, having the time to do that would be nice.  A cursory look at
the .diff files doesn't reveal anything blatantly obvious.  Only
three potential candidates:

+2002-10-04  Roger Sayle  <roger@eyesopen.com>
+
+       * config/i386/i386.h (processor_costs): Add new fields fadd,
+       fmul, fdiv, fabs, fchs and fsqrt to costs structure.
+       (RTX_COSTS): Use these fields to determine the RTX costs
+       of floating point addition/subtraction, multiplication,
+       division, fabs, negation and square root respectively.
+       * config/i386/i386.c (size_cost): Provide instruction sizes
+       for these new fields.
+       (i386_cost, i486_cost, pentium_cost, pentiumpro_cost,
+       k6_cost, athlon_cost, pentium4_cost): Provide typical cycle
+       counts for these new fields for all x86 processor variants.
+

+2002-10-04  Richard Henderson  <rth@redhat.com>
+
+       * real.h (SIGNIFICAND_BITS): Add one more word.
+       (CONST_DOUBLE_FORMAT): Accomodate 6 words.
+       * real.c (times_pten): New.
+       (real_to_decimal, real_from_string): Use it.
+       (sticky_rshift_significand): Use & to find modulus.
+       (rshift_significand, lshift_significand): Likewise.
+       (do_divide): Apply sticky bit after normalization.
+       (real_to_decimal, real_to_hexadecimal): Fix sign of Inf and NaN.
+

+2002-10-04  David Edelsohn  <edelsohn@gnu.org>
+
+       * unroll.c (copy_loop_body): Remove REG_EQUAL note attached to
+       copied instruction if the note is not loop invariant.
+

But neither should have had any effects on SPECint.  Anyway, I'll
start undoing patches as time permits.


Diego.

Re: Bootstrap times on mainline are getting worse

[David Edelsohn]

>>>>> Diego Novillo writes:

Diego> +2002-10-04  David Edelsohn  <edelsohn@gnu.org>
Diego> +
Diego> +       * unroll.c (copy_loop_body): Remove REG_EQUAL note attached to
Diego> +       copied instruction if the note is not loop invariant.
Diego> +

Diego> But neither should have had any effects on SPECint.  Anyway, I'll
Diego> start undoing patches as time permits.

	My patch only should have an effect when unrolling is enabled,
which it is not by default when bootstrapping.  I am worried about the
performance impact with -funroll-loops, but I checked the SPEC runs and
did not see a dramatic change.

	Also, this slow-down could be due to the increasing complexity of
the x86 port, not a generic slow-down in the common parts of the
compiler.  More complete cost models and register classes increase the
complexity of the port and the time spent in various
architecture-dependent compiler phases.

David

Re: Bootstrap times on mainline are getting worse

[Pop Sébastian]

On Fri, Oct 18, 2002 at 11:34:11AM -0400, Diego Novillo wrote:
> On Fri, 18 Oct 2002, Kaveh R. Ghazi wrote:
> 
> > Care to take a stab?
> > 
> Heh, having the time to do that would be nice.  A cursory look at
> the .diff files doesn't reveal anything blatantly obvious.  Only
> three potential candidates:
> 
> +2002-10-04  Roger Sayle  <roger@eyesopen.com>
> +
> +       * config/i386/i386.h (processor_costs): Add new fields fadd,
> +       fmul, fdiv, fabs, fchs and fsqrt to costs structure.
> +       (RTX_COSTS): Use these fields to determine the RTX costs
> +       of floating point addition/subtraction, multiplication,
> +       division, fabs, negation and square root respectively.
> +       * config/i386/i386.c (size_cost): Provide instruction sizes
> +       for these new fields.
> +       (i386_cost, i486_cost, pentium_cost, pentiumpro_cost,
> +       k6_cost, athlon_cost, pentium4_cost): Provide typical cycle
> +       counts for these new fields for all x86 processor variants.
> +
> 
A 'time make bootstrap' on version "2002-10-03" gives:

real    57m38.632s
user    51m20.200s
sys     4m55.500s


With this patch I get:

real    58m16.766s
user    51m14.720s
sys     5m0.850s


$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) 4 Processor
stepping        : 2
cpu MHz         : 1399.803
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips        : 2791.83

Re: Bootstrap times on mainline are getting worse

[Zack Weinberg]

On Sat, Oct 19, 2002 at 11:52:06AM +0200, Pop Sébastian wrote:
> On Fri, Oct 18, 2002 at 11:34:11AM -0400, Diego Novillo wrote:
> > On Fri, 18 Oct 2002, Kaveh R. Ghazi wrote:
> > 
> > > Care to take a stab?
> > > 
> > Heh, having the time to do that would be nice.  A cursory look at
> > the .diff files doesn't reveal anything blatantly obvious.  Only
> > three potential candidates:
> > 
> > +2002-10-04  Roger Sayle  <roger@eyesopen.com>
> > +
> > +       * config/i386/i386.h (processor_costs): Add new fields fadd,
> > +       fmul, fdiv, fabs, fchs and fsqrt to costs structure.
> > +       (RTX_COSTS): Use these fields to determine the RTX costs
> > +       of floating point addition/subtraction, multiplication,
> > +       division, fabs, negation and square root respectively.
> > +       * config/i386/i386.c (size_cost): Provide instruction sizes
> > +       for these new fields.
> > +       (i386_cost, i486_cost, pentium_cost, pentiumpro_cost,
> > +       k6_cost, athlon_cost, pentium4_cost): Provide typical cycle
> > +       counts for these new fields for all x86 processor variants.
> > +
> > 
> A 'time make bootstrap' on version "2002-10-03" gives:
> 
> real    57m38.632s
> user    51m20.200s
> sys     4m55.500s
> 
> 
> With this patch I get:
> 
> real    58m16.766s
> user    51m14.720s
> sys     5m0.850s

I smell cache blowout.  Notice how the real and system times went up,
but the user time went down?

The processor_costs tables are entirely populated with values which we
can reasonably expect will never rise above 256.  So I propose to
change all the fields to unsigned char.  Would you mind trying out the
appended patch on top of 2002-10-03+Roger's patch?

zw

	* config/i386/i386.h (struct processor_costs):
	Make all fields const unsigned char.

===================================================================
Index: config/i386/i386.h
--- config/i386/i386.h	19 Oct 2002 08:48:37 -0000	1.297
+++ config/i386/i386.h	19 Oct 2002 17:16:36 -0000
@@ -37,50 +37,53 @@ Boston, MA 02111-1307, USA.  */
 /* Define the specific costs for a given cpu */
 
 struct processor_costs {
-  const int add;		/* cost of an add instruction */
-  const int lea;		/* cost of a lea instruction */
-  const int shift_var;		/* variable shift costs */
-  const int shift_const;	/* constant shift costs */
-  const int mult_init;		/* cost of starting a multiply */
-  const int mult_bit;		/* cost of multiply per each bit set */
-  const int divide;		/* cost of a divide/mod */
-  int movsx;			/* The cost of movsx operation.  */
-  int movzx;			/* The cost of movzx operation.  */
-  const int large_insn;		/* insns larger than this cost more */
-  const int move_ratio;		/* The threshold of number of scalar
-				   memory-to-memory move insns.  */
-  const int movzbl_load;	/* cost of loading using movzbl */
-  const int int_load[3];	/* cost of loading integer registers
-				   in QImode, HImode and SImode relative
-				   to reg-reg move (2).  */
-  const int int_store[3];	/* cost of storing integer register
-				   in QImode, HImode and SImode */
-  const int fp_move;		/* cost of reg,reg fld/fst */
-  const int fp_load[3];		/* cost of loading FP register
-				   in SFmode, DFmode and XFmode */
-  const int fp_store[3];	/* cost of storing FP register
-				   in SFmode, DFmode and XFmode */
-  const int mmx_move;		/* cost of moving MMX register.  */
-  const int mmx_load[2];	/* cost of loading MMX register
-				   in SImode and DImode */
-  const int mmx_store[2];	/* cost of storing MMX register
-				   in SImode and DImode */
-  const int sse_move;		/* cost of moving SSE register.  */
-  const int sse_load[3];	/* cost of loading SSE register
-				   in SImode, DImode and TImode*/
-  const int sse_store[3];	/* cost of storing SSE register
-				   in SImode, DImode and TImode*/
-  const int mmxsse_to_integer;	/* cost of moving mmxsse register to
-				   integer and vice versa.  */
-  const int prefetch_block;	/* bytes moved to cache for prefetch.  */
-  const int simultaneous_prefetches; /* number of parallel prefetch
-				   operations.  */
-  const int fadd;		/* cost of FADD and FSUB instructions.  */
-  const int fmul;		/* cost of FMUL instruction.  */
-  const int fdiv;		/* cost of FDIV instruction.  */
-  const int fabs;		/* cost of FABS instruction.  */
-  const int fchs;		/* cost of FCHS instruction.  */
-  const int fsqrt;		/* cost of FSQRT instruction.  */
+#define cuchar const unsigned char
+  cuchar add;		/* cost of an add instruction */
+  cuchar lea;		/* cost of a lea instruction */
+  cuchar shift_var;	/* variable shift costs */
+  cuchar shift_const;	/* constant shift costs */
+  cuchar mult_init;	/* cost of starting a multiply */
+  cuchar mult_bit;	/* cost of multiply per each bit set */
+  cuchar divide;	/* cost of a divide/mod */
+  cuchar movsx;		/* The cost of movsx operation.  */
+  cuchar movzx;		/* The cost of movzx operation.  */
+  cuchar large_insn;	/* insns larger than this cost more */
+  cuchar move_ratio;	/* The threshold of number of scalar
+			   memory-to-memory move insns.  */
+  cuchar movzbl_load;	/* cost of loading using movzbl */
+  cuchar int_load[3];	/* cost of loading integer registers
+			   in QImode, HImode and SImode relative
+			   to reg-reg move (2).  */
+  cuchar int_store[3];	/* cost of storing integer register
+			   in QImode, HImode and SImode */
+  cuchar fp_move;	/* cost of reg,reg fld/fst */
+  cuchar fp_load[3];	/* cost of loading FP register
+			   in SFmode, DFmode and XFmode */
+  cuchar fp_store[3];	/* cost of storing FP register
+			   in SFmode, DFmode and XFmode */
+  cuchar mmx_move;	/* cost of moving MMX register.  */
+  cuchar mmx_load[2];	/* cost of loading MMX register
+			   in SImode and DImode.   */
+  cuchar mmx_store[2];	/* cost of storing MMX register
+			   in SImode and DImode.  */
+  cuchar sse_move;	/* cost of moving SSE register.  */
+  cuchar sse_load[3];	/* cost of loading SSE register
+			   in SImode, DImode and TImode.  */
+  cuchar sse_store[3];	/* cost of storing SSE register
+			   in SImode, DImode and TImode.  */
+  cuchar mmxsse_to_integer;
+			 /* cost of moving mmxsse register to integer
+			    and vice versa.  */
+  cuchar prefetch_block; /* bytes moved to cache for prefetch.  */
+  cuchar simultaneous_prefetches;
+  			 /* number of parallel prefetch operations.  */
+  cuchar fadd;		 /* cost of FADD and FSUB instructions.  */
+  cuchar fmul;		 /* cost of FMUL instruction.  */
+  cuchar fdiv;		 /* cost of FDIV instruction.  */
+  cuchar fabs;		 /* cost of FABS instruction.  */
+  cuchar fchs;		 /* cost of FCHS instruction.  */
+  cuchar fsqrt;		 /* cost of FSQRT instruction.  */
+#undef cuchar
 };
 
 extern const struct processor_costs *ix86_cost;

Re: Bootstrap times on mainline are getting worse

[Pop Sébastian]

On Sat, Oct 19, 2002 at 10:17:41AM -0700, Zack Weinberg wrote:
> > 
> > real    57m38.632s
> > user    51m20.200s
> > sys     4m55.500s
> > 
> > 
> > With this patch I get:
> > 
> > real    58m16.766s
> > user    51m14.720s
> > sys     5m0.850s
> 
> I smell cache blowout.  Notice how the real and system times went up,
> but the user time went down?
> 
I/O activity on the same machine could be the reason of this increase of
the sys time... (I'm not the only one to use this machine)

Maybe I have to run more than once 'time make bootstrap' for having an 
average value.  3 seems to be a good value. Another solution is to run 
the 'time make bootstrap' on 2 different machines... 

> The processor_costs tables are entirely populated with values which we
> can reasonably expect will never rise above 256.  So I propose to
> change all the fields to unsigned char.  Would you mind trying out the
> appended patch on top of 2002-10-03+Roger's patch?
> 
I will do.

I have tried to bootstrap a version of 2002-10-05 and 2002-10-06, 
but the bootstrap stopped on an error trying to build 
libstdc++-v3/src/ext-inst.cc

I've bootstrapped again the 2002-10-03 on the same machine, 

real    57m30.512s
user    51m10.860s
sys     4m57.940s

then I'll bootstrap again 2002-10-03 + Roger's patch, 
and finally I'll bootstrap 2002-10-03 + Roger's patch + your patch.

I try to bootstrap the 2002-10-07 on another machine, results will come shortly.


Sebastian

Re: Bootstrap times on mainline are getting worse

[Pop Sébastian]

On Sat, Oct 19, 2002 at 10:40:04PM +0200, Pop Sébastian wrote:
> On Sat, Oct 19, 2002 at 10:17:41AM -0700, Zack Weinberg wrote:
> > > 
> > > real    57m38.632s
> > > user    51m20.200s
> > > sys     4m55.500s
> > > 
> > > 
> > > With this patch I get:
> > > 
> > > real    58m16.766s
> > > user    51m14.720s
> > > sys     5m0.850s
> > 
> 
> I've bootstrapped again the 2002-10-03 on the same machine, 
> 
> real    57m30.512s
> user    51m10.860s
> sys     4m57.940s
> 
> then I'll bootstrap again 2002-10-03 + Roger's patch, 

real    57m17.188s
user    51m1.780s
sys     5m0.720s

> and finally I'll bootstrap 2002-10-03 + Roger's patch + your patch.
> 
> I try to bootstrap the 2002-10-07 on another machine, results will come shortly.
> 
This failed again on the same error...

Re: Bootstrap times on mainline are getting worse

[Pop Sébastian]

Version 2002-10-03:

real    57m38.632s
user    51m20.200s
sys     4m55.500s

real    57m30.512s
user    51m10.860s
sys     4m57.940s


Version 2002-10-03 + Roger's patch:

real    58m16.766s
user    51m14.720s
sys     5m0.850s

real    57m17.188s
user    51m1.780s
sys     5m0.720s


Version 2002-10-03 + Roger's patch + Zack's patch:

real    57m12.912s
user    51m8.120s
sys     4m57.050s


Size of stage3:

GNU C version 3.3 20021002 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.3 20021002 (experimental)
+ Roger's patch + Zack's patch

10267822  cc1
10412113  cc1obj
12695853  cc1plus

I don't have the sizes of stage3 before Zack's patch since I 
removed the bin directory before bootstrapping again.

I have the sizes for:

GNU C version 3.3 20021005 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.3 20021005 (experimental).
(which failed to compile libstdc++)

10340506 cc1
10484949 cc1obj
12768801 cc1plus


GNU C version 3.3 20021006 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.3 20021006 (experimental).
(which failed to compile libstdc++)

10360417  cc1
10504580  cc1obj
12790373  cc1plus

Re: Bootstrap times on mainline are getting worse

[Pop Sébastian]

On Fri, Oct 18, 2002 at 10:27:56AM -0400, Kaveh R. Ghazi wrote:
> > 
> > For CINT95 base, we have a 6% increase in build times since
> > Sep19.  There is a noticeable jump around Oct06.
> > Diego.
> 
> Ok that settles it, thanks for checking.
> 
> Since it's so sharp, now we just need someone to binary search Oct 5-7
> and figure out which patch did it.
> 

Here are the results from bootstraps with --enable-languages=c on a 

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(tm) 4 Processor
stepping        : 2
cpu MHz         : 1399.803
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips        : 2791.83



2002-10-01
1031.64user 26.01system 17:39.48elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1331964major+1923997minor)pagefaults 0swaps

2002-10-02
1031.94user 26.85system 17:40.46elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1333330major+1923697minor)pagefaults 0swaps
 
2002-10-03
1032.39user 26.72system 17:41.04elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1332002major+1920326minor)pagefaults 0swaps
 
2002-10-04
1038.00user 26.83system 17:50.54elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1337908major+1929463minor)pagefaults 0swaps
 
2002-10-05
1057.46user 26.99system 18:06.25elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1340221major+1926491minor)pagefaults 0swaps
 
2002-10-06
1084.83user 27.42system 18:34.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1361961major+1998615minor)pagefaults 0swaps
 
2002-10-07
1083.19user 27.40system 18:34.31elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1361403major+1998864minor)pagefaults 0swaps
 
2002-10-08
1083.89user 27.08system 18:32.71elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1361288major+1999996minor)pagefaults 0swaps
 
2002-10-09
1089.31user 27.22system 18:38.29elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1363081major+2003417minor)pagefaults 0swaps
 
2002-10-10
1090.98user 27.51system 18:42.02elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1365772major+2003646minor)pagefaults 0swaps
 
2002-10-11
1090.32user 26.88system 18:39.05elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1365403major+2003692minor)pagefaults 0swaps
 
2002-10-12
1085.83user 27.14system 18:34.73elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1360931major+2003402minor)pagefaults 0swaps
 
2002-10-13
1084.79user 26.93system 18:33.35elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1360943major+2003488minor)pagefaults 0swaps
 
2002-10-14
1084.87user 27.38system 18:33.80elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1360628major+2002780minor)pagefaults 0swaps
 
2002-10-15
1084.76user 27.18system 18:33.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1361839major+2001324minor)pagefaults 0swaps
 
----
user_time  total_time
+0.45      +0:00.58    from 02 to 03 oct
+5.61      +0:09.50    from 03 to 04 oct
+19.46     +0:15.71    from 04 to 05 oct
+27.37     +0:27.90    from 05 to 06 oct
-1.64      +0:00.16    from 06 to 07 oct

----
Beginning with 2002-10-06 and removing successively patches:

1084.83user 27.42system 18:34.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1361961major+1998615minor)pagefaults 0swaps
(user_time = 1084.83)


-  2002-10-05  Jakub Jelinek  <jakub@redhat.com>

	* gcc.c (set_multilib_dir): Don't access *end.
        Use memcpy instead of strncpy.  Don't write beyond malloced buffer.
        (print_multilib_info): Don't show paths starting with ".:".
        * genmultilib: Add new option, "yes" if multilibs are enabled.
        Update comments.  If multilibs not enabled, print .:${osdirout}
        for each directory.  If multilibs are enabled, always print
        ${dirout}:${osdirout}, even if the two are the same.
        * Makefile.in (s-mlib): Pass @enable_multilib@ to genmultilib.
        Pass all MULTILIB_* variables to genmultilib even if
        --disable-multilib but MULTILIB_OSDIRNAMES is not empty.

1088.74user 27.53system 18:37.93elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1365850major+2006331minor)pagefaults 0swaps
(user_time += 3.09)

-  2002-10-04  Bruce Korb  <bkorb@gnu.org>

	* fixinc/inclhack.def(hpux11_abs):  use format fix
        * fixinc/fixincl.x: regenerate
        * fixinc/tests/base/stdlib.h: accommodate new fix test

   2002-10-04  Steve Ellcey  <sje@cup.hp.com>

        * fixinc/inclhack.def (hpux11_abs):  New.
        (stdio_va_list): change __va_list__ to __gnuc_va_list.
        * fixinc/fixincl.x: Rebuild.

1074.80user 27.84system 18:24.60elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1360966major+1991862minor)pagefaults 0swaps
(user_time -= 13.94)

-  Sat Oct  5 19:42:45 CEST 2002  Jan Hubicka  <jh@suse.cz>

	* c-common.c (cb_register_builtins):  Use really_no_inline.

1053.88user 26.71system 18:02.14elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1338140major+1921724minor)pagefaults 0swaps
(user_time -= 20.92)

-  2002-10-04  David Edelsohn  <edelsohn@gnu.org>

	* unroll.c (copy_loop_body): Remove REG_EQUAL note attached to
        copied instruction if the note is not loop invariant.

1049.06user 26.07system 17:56.97elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1343127major+1922752minor)pagefaults 0swaps
(user_time -= 4.82)

-  2002-10-04  Loren J. Rittle  <ljrittle@acm.org>

	* gcc/ginclude/stddef.h: Support the FreeBSD 5 typedef system.

1045.45user 26.39system 18:03.49elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1336632major+1920493minor)pagefaults 0swaps
(user_time -= 3.61)

-  2002-10-04  Roger Sayle  <roger@eyesopen.com>

	* config/i386/i386.h (processor_costs): Add new fields fadd,
        fmul, fdiv, fabs, fchs and fsqrt to costs structure.
        (RTX_COSTS): Use these fields to determine the RTX costs
        of floating point addition/subtraction, multiplication,
        division, fabs, negation and square root respectively.
        * config/i386/i386.c (size_cost): Provide instruction sizes
        for these new fields.
        (i386_cost, i486_cost, pentium_cost, pentiumpro_cost,
        k6_cost, athlon_cost, pentium4_cost): Provide typical cycle
        counts for these new fields for all x86 processor variants.

1044.86user 27.02system 17:53.47elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1333518major+1918826minor)pagefaults 0swaps
(user_time -= 0.59)

-  2002-10-04  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

        * mips.c (mips_const_double_ok): Delete unused variable.

        * gengtype.c (rtx_next): Change type to int.

   2002-10-03  Andreas Jaeger  <aj@suse.de>

        * gengtype.c (adjust_field_rtx_def): Cast variables of type size_t
        to unsigned long, adjust printf format string.
        (output_mangled_typename): Likewise.

1044.87user 26.91system 17:53.38elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1333518major+1919257minor)pagefaults 0swaps
(user_time += 0.01)

-  2002-10-04  Richard Henderson  <rth@redhat.com>

        * real.h (SIGNIFICAND_BITS): Add one more word.
        (CONST_DOUBLE_FORMAT): Accomodate 6 words.
        * real.c (times_pten): New.
        (real_to_decimal, real_from_string): Use it.
        (sticky_rshift_significand): Use & to find modulus.
        (rshift_significand, lshift_significand): Likewise.
        (do_divide): Apply sticky bit after normalization.
        (real_to_decimal, real_to_hexadecimal): Fix sign of Inf and NaN.

   2002-10-03  Richard Henderson  <rth@redhat.com>

        * real.h (struct real_value): Use ENUM_BITFIELD.

1023.81user 26.66system 17:31.84elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1334089major+1922497minor)pagefaults 0swaps
(user_time -= 21.06)


-  Thu Oct  3 23:35:51 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * i386.c (athlon_cost): Fix the move costs.

   Thu Oct  3 23:20:58 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * final.c (final): Use symbol name as function name for profiling.
        * profile.c (get_exec_counts): Likewise.
        (branch_prob): Likewise.

   Thu Oct  3 21:42:20 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * predict.c (choose_function_section): Avoid choice for linkonce functions.

   Thu Oct  3 15:15:00 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * i386.md (lea to mul peep2): Fix condition.

   Wed Oct  2 17:01:36 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * i386.c (print_operand_address): Use RIP addressing for offsetted
        label refs too.

1023.66user 26.36system 17:32.54elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1332099major+1920638minor)pagefaults 0swaps
(user_time -= 0.15)

----
Summary:
There are 3 patches that make bootstrap times slower:

+03.09
-13.94  2002-10-04  Bruce Korb  <bkorb@gnu.org> and Steve Ellcey
-20.92  Sat Oct  5 19:42:45 CEST 2002  Jan Hubicka  <jh@suse.cz>
-04.82
-03.61
-00.59
+00.01
-21.06  2002-10-04  Richard Henderson  <rth@redhat.com>
-00.15

Re: Bootstrap times on mainline are getting worse

[Neil Booth]

Diego Novillo wrote:-

> http://people.redhat.com/dnovillo/spec95/gcc/gcc-stats.html
> 
> Bootstrap times have been creeping up lately.  Today's mainline
> is 10% slower to bootstrap C and Fortran than a month ago.
> The biggest increase in bootstrap times seems to have come after
> Oct05.

This is truly depressing.  There seems to be nothing we can do
to prevent it.

Neil.

Re: Bootstrap times on mainline are getting worse

[Diego Novillo]

On Thu, 17 Oct 2002, Neil Booth wrote:

> > http://people.redhat.com/dnovillo/spec95/gcc/gcc-stats.html
> > 
> > Bootstrap times have been creeping up lately.  Today's mainline
> > is 10% slower to bootstrap C and Fortran than a month ago.
> > The biggest increase in bootstrap times seems to have come after
> > Oct05.
> 
> This is truly depressing.  There seems to be nothing we can do
> to prevent it.
> 
Well, on the bright side,  we can now examine the collection of
patches that may have caused the regression (they're all stored
with the SPEC tester).

But that assumes that we have enough volunteer cycles to actually
go through them.


Diego.

Re: Bootstrap times on mainline are getting worse

[Robert Dewar]

>>This is truly depressing.  There seems to be nothing we can do
to prevent it.

At the very least,we could measure the bootstrap performance impact of
each patch.

I must say the cumulative difference is quite noticeable. I am switching
from using OS/2, GCC 2.8.1 on a 300MHz P3, to XP, GCC 3.2, 1.3 GHz P3,
and the compilation time is about the same, yes there are other variables
(OS/2 is definitely a lot more efficient than XP), but still a significant
difference.

Re: Bootstrap times on mainline are getting worse

[Diego Novillo]

On Thu, 17 Oct 2002, Robert Dewar wrote:

> >>This is truly depressing.  There seems to be nothing we can do
> to prevent it.
> 
> At the very least,we could measure the bootstrap performance impact of
> each patch.
> 
We are, in a way.  With every run we save the differences between
today's tree and the previous one.  That may include more than
one patch, but in general is not a big set.


Diego.

Re: Bootstrap times on mainline are getting worse

[Roger Sayle]

Hi Pop,
> > +2002-10-04  Roger Sayle  <roger@eyesopen.com>
> > +
> > +       * config/i386/i386.h (processor_costs): Add new fields fadd,
> > +       fmul, fdiv, fabs, fchs and fsqrt to costs structure.
> > +       (RTX_COSTS): Use these fields to determine the RTX costs
> > +       of floating point addition/subtraction, multiplication,
> > +       division, fabs, negation and square root respectively.
> > +       * config/i386/i386.c (size_cost): Provide instruction sizes
> > +       for these new fields.
> > +       (i386_cost, i486_cost, pentium_cost, pentiumpro_cost,
> > +       k6_cost, athlon_cost, pentium4_cost): Provide typical cycle
> > +       counts for these new fields for all x86 processor variants.
> > +
> >
> A 'time make bootstrap' on version "2002-10-03" gives:
>
> real    57m38.632s
> user    51m20.200s
> sys     4m55.500s
>
> With this patch I get:
>
> real    58m16.766s
> user    51m14.720s
> sys     5m0.850s

Thanks for ruling out this patch as the cause of the performance
regression.  It reduces the CPU time by 6 seconds, and the change
in wall clock times, 3496 seconds vs. 3458 seconds, is 1% and far
less than the 6% regression we're looking for.  I'm guessing both
these timings are within the natural fluctuation (I won't take
credit for the 6s :)

I initially misread your posting as implying this patch was to
blame, and spent several minutes trying to work out how calling
FLOAT_TYPE_P (GET_MODE (X)) on a critical path would cause a
four minute slow down in bootstrap times.  GCC doesn't use host
floating point, so I came to the obvious conclussion that
RTX_COSTS must account for >5% of GCC's CPU time, but just
doesn't show up in profile.  Swift reality check and "Reductio
ad absurdum".

Many thanks for investigating this.  One down, a few more to go.

Roger
--

Re: Bootstrap times on mainline are getting worse

[Roger Sayle]

Hi Zack,

> > A 'time make bootstrap' on version "2002-10-03" gives:
> >
> > real    57m38.632s
> > user    51m20.200s
> > sys     4m55.500s
> >
> > With this patch I get:
> >
> > real    58m16.766s
> > user    51m14.720s
> > sys     5m0.850s
>
> I smell cache blowout.  Notice how the real and system times went up,
> but the user time went down?

I think that you're barking up the wrong tree on this one.  As I've
mentioned in http://gcc.gnu.org/ml/gcc/2002-10/msg01183.html, we're
still looking for a 6% (approx 4 minute slow-down) around October 5th.

Total process times above, 56m:15.7 before and 56m:15.5 after showed
that this patch itself had virtually no effect.  The minor difference
in wall clock times can easily be explained by attributed to other
processes running on the same machine.

Also be carefull about changing these RTX costs to unsigned char.
Pentium4 already has integer division costs at around 120, and
improvements in superscalar issue vs memory latency could easily
push values above 256 on x86 within only a year or so.  Just look
at the curves for i386, i486, pentium, pentiumpro, pentium4....

Roger
--

Re: Bootstrap times on mainline are getting worse

[Zack Weinberg]

On Sat, Oct 19, 2002 at 11:25:55AM -0600, Roger Sayle wrote:
> 
> Hi Zack,
> 
> > > A 'time make bootstrap' on version "2002-10-03" gives:
> > >
> > > real    57m38.632s
> > > user    51m20.200s
> > > sys     4m55.500s
> > >
> > > With this patch I get:
> > >
> > > real    58m16.766s
> > > user    51m14.720s
> > > sys     5m0.850s
> >
> > I smell cache blowout.  Notice how the real and system times went up,
> > but the user time went down?
> 
> I think that you're barking up the wrong tree on this one.  As I've
> mentioned in http://gcc.gnu.org/ml/gcc/2002-10/msg01183.html, we're
> still looking for a 6% (approx 4 minute slow-down) around October 5th.

Yeah, I wrote this before I saw your message.

I still think it's worth shrinking processor_costs - we're getting
nickled and dimed to death on cache utilization, and this is a cheap
way to get quite a bit of space back.

> Also be carefull about changing these RTX costs to unsigned char.
> Pentium4 already has integer division costs at around 120, and
> improvements in superscalar issue vs memory latency could easily
> push values above 256 on x86 within only a year or so.  Just look
> at the curves for i386, i486, pentium, pentiumpro, pentium4....

The only thing that's really gone up is the integer divide cost.  Even
load/store costs are stable in the 2-16 cycles range (presumably this
is cost to fetch from L1 cache).  I'd wait until we really do have a
cost above 256 and then change just that one entry to unsigned short.

zw

Re: Bootstrap times on mainline are getting worse

[Roger Sayle]

> I still think it's worth shrinking processor_costs - we're getting
> nickled and dimed to death on cache utilization, and this is a cheap
> way to get quite a bit of space back.

I agree it does no harm, and potentially some good.  Saving a few
hundred bytes is a step in the right direction, even if it'll have
little overall effect on GCC's multi-megabyte memory footprint.


> I'd wait until we really do have a cost above 256 and then change
> just that one entry to unsigned short.

Sounds very reasonable.


Roger
--

Re: Bootstrap times on mainline are getting worse

[Zack Weinberg]

On Sat, Oct 19, 2002 at 12:47:04PM -0600, Roger Sayle wrote:
> 
> > I still think it's worth shrinking processor_costs - we're getting
> > nickled and dimed to death on cache utilization, and this is a cheap
> > way to get quite a bit of space back.
> 
> I agree it does no harm, and potentially some good.

Thinking about it a bit more, the gain could be totally wiped out by
having to do more work to access byte fields.  I don't think this is a
problem for an x86 native compiler, but it'd be useful to
know. Sebastian, could you post size -A reports for stage3 cc1 before
and after the patch?

> Saving a few hundred bytes is a step in the right direction, even if
> it'll have little overall effect on GCC's multi-megabyte memory
> footprint.

I should finish the bytecoded-insn-recog.c patch RTH and I started
back in 1999.  How does ~200K off the size of the text segment sound?
(at a cost of 20-50K in .rodata, IIRC)

zw

Re: Bootstrap times on mainline are getting worse

[Geert Bosch]

Roger wrote:
> Also be carefull about changing these RTX costs to unsigned char.
> Pentium4 already has integer division costs at around 120, and
> improvements in superscalar issue vs memory latency could easily
> push values above 256 on x86 within only a year or so.  Just look
> at the curves for i386, i486, pentium, pentiumpro, pentium4....

I don't see how it can hurt to max out the cost at some point.
If we select an instruction with a cost higher than 100, it must
mean there is little alternative but to use that instruction.

   -Geert

Re: Bootstrap times on mainline are getting worse

[Tim Prince]

On Saturday 19 October 2002 11:57, Geert Bosch wrote:
> Roger wrote:
> > Also be carefull about changing these RTX costs to unsigned char.
> > Pentium4 already has integer division costs at around 120, and
> > improvements in superscalar issue vs memory latency could easily
> > push values above 256 on x86 within only a year or so.  Just look
> > at the curves for i386, i486, pentium, pentiumpro, pentium4....
>
> I don't see how it can hurt to max out the cost at some point.
> If we select an instruction with a cost higher than 100, it must
> mean there is little alternative but to use that instruction.
>
>    -Geert
I understand there are examples where the high costs assessed for P4 shift 
and multiply produce slower code, since long add sequences may exceed trace 
cache capacity in practical contexts.  Processor variants are coming along 
with P4 instruction set compatibility, with smaller latencies.  I usually 
modify the costs arbitrarily to come closer to the Intel P4 Optimization 
Guide recommended instruction sequence choice trade points.
-- 
Tim Prince