This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: splitting insn-attrtab.c? (was: [patch] Tighten pre-requisites for parallel make)


On Mon, 2009-04-20 at 09:39 +0200, Paolo Bonzini wrote:
> Ralf Wildenhues wrote:
> > Hello Michael,
> > 
> > * Michael Matz wrote on Mon, Apr 20, 2009 at 04:14:31AM CEST:
> >> we use order-only pre-requisites of GNU make to make sure that the 
> >> generated files are generated very early.
> > 
> > Yes, but we also used it to direct 'make' to compile insn-attrtab as
> > soon as possible.  It may well be that we didn't try this change that
> > you have now, or some other circumstance didn't let this seem beneficial
> > then.  Which make version did you test with?
> 
> insn-attrtab is compiled as soon as possible anyway because it's at the
> top of OBJS-common.

On the compile farm at make -j 8 on a x86_64 bi-quad each stage
insn-attrtab.c compilation finishes alone. I did some measurement on
gcc16 with the flags from bootstrap log (-g -O2 & others):

Last stage compilation of insn-attrtab.c, best of 5 runs:
real	2m59.548s
user	2m58.359s
sys	0m1.188s

Lines:
150234 insn-attrtab.c

I manually splitted the file by putting the 70 klines
internal_dfa_insn_code function plus a copy of include list in a
separate file x1.c, the rest left in x0.c, results:

Lines:
  80081 x0.c
  70175 x1.c
 150256 total

Compiling x0.c, best of 5 runs:
real	1m6.480s
user	1m5.824s
sys	0m0.656s

Compiling x1.c, best of 5 runs:
real	1m54.334s
user	1m53.435s
sys	0m0.900s

Total best: 3m01s

I measured compiling the includes plus just insn_current_length, a small
function, at 0.4s so for the best time it seems coherent as overhead. 

I observed significant variance in my measurement even if the machine
was not loaded, sometimes up to +30 seconds for a given compile,
I have no explanation for this variance. Memory used goes up to 330MB.

For reference, compiling insn-attrtab.c at -O0 (instead of -O2) is about
29 seconds, at -O1: 1mn32s.

So for x86_64 splitting this generated file in two following what I did
manually would lead to a very modest slowdown in the -j 1 case
(about two seconds if measurable) and in theory for -j N with N >=2
about 3 minutes ouf of 24 minutes at -j 8 on gcc16.

On other platforms I don't know if insn-attrtab.c is showing on the
radar.

Opinions?

Thanks in advance,

Laurent




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]