PR 10196 / Re: Inliner parameters

[Richard Guenther]

On Thu, 17 Apr 2003, Richard Guenther wrote:

> On 17 Apr 2003, Steven Bosscher wrote:
>
> > Op wo 16-04-2003, om 23:17 schreef Richard Guenther:
> > > > When was the last time somebody tried to tune the parameters a bit?  Did
> > > > anyone try the effects of different parameter settings for, say, SPEC
> > > > and POOMA (and, ideally, on more than one platform)?
> > >
> > > I tried various parameters for POOMA to tune the performance of the
> > > optimized code and the key parameter to change was min-inline-insns.
> > > This is _way_ too low for POOMA to collapse the expression template
> > > trees. I need to bump this up to 250 to get good performance. The
> > > max-inline-insns-single can be dropped to 250 without loss then.
> >
> > What happened to the compile times with bigger min-inline-insns?
>
> Here are compile time and runtime numbers for my performace testcase using
> g++-3.3 (GCC) 3.3 20030414 (prerelease) with options -O2 -march=athlon
> -fomit-frame-pointer -funroll-loops -fno-exceptions --param min-inline-insns=X.
> Lower numbers for the perf. indicator are better.
>
>   X      compile-time    performance indicator
> default     49.50           1.99804e-06
>  50         50.25           2.26817e-06
> 100         50.00           1.96918e-06
> 150         51.00           1.90269e-06
> 200         58.25           1.83045e-06
> 250         61.25           1.28309e-06
> 300         62.75           1.29364e-06
> default + -Dinline="__inline__ __attribute__((always_inline))"
>             50.50           1.31171e-06
> (while the source is not optimized for inline->always_inline
> transformation)
>
> just to show what happens with EH on, for the best param above (250)
> we get
>
> 250         [again, goes into swap... - till then, 3min elapsed]
> killed it - going to a machine with 2GB ram and more GHz where we cant
> compare the compile time numbers from above, of course...
> 250        448.00 [uses 750MB of ram]  5.96641e-07
> which is more than an order of magnitude worse than without EH on a
> faster CPU with faster mem... ugh!

With g++-3.3 (GCC) 3.3 20030423 (prerelease) I now get

250     79.75 [154MB]     1.2667e-06

which is not only a lot better in compile time and in memory usage, but
also on-par in performance with the -fno-exceptions case.

Just to repeat the -fno-exceptions case, with the new gcc I get

250     63.75 [153MB]     1.26749e-06

so compile time is still worse for exceptions turned on, but that is to
be expected anyway. Just for the curious, here are the g++-3.2 (GCC) 3.2.3
20030414 (prerelease) numbers:

with exceptions (default inlining params)

default  63.00 [170MB]   1.96574e-06

without exceptions (default inlining params)

default  54.00 [161MB]   1.97593e-06


The testcase for PR10196 now shows:

g++-3.3 -fno-exceptions: 11.75s
g++-3.3 -fexceptions:    14.75s
g++-3.2 -fno-exceptions:  9.50s
g++-3.2 -fexceptions:    11.50s

which is _a lot_ better, but still a 19% regression for -fno-exceptions
and a 22% regression for -fexceptions. But as these numbers are below
30%, we can now downgrade the priority of the PR?


Btw., using libstdc++ from gcc-3.3 with code compiled with gcc-3.2 gives
/LINUXgcc32/Bench: relocation error: ./LINUXgcc32/Bench: symbol
_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,
version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time
reference

the other way around its similar. Maybe libstdc++ version needs to be
bumped for 3.3?

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/