Re: PR 10196 / Re: Inliner parameters

Re: PR 10196 / Re: Inliner parameters

[Steven Bosscher]

Op wo 23-04-2003, om 13:36 schreef 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?

Part of that 30% can probably be explained with PR 8361, but inlining
still is slower, and there should be a PR for that, I think.

So I propose we close PR 10316, and we either close 10196 and open a new
PR for the inliner slowdown, or we leave 10196 open with a remark in the
audit trail.  Does that sound OK to you?

Greetz
Steven

Re: PR 10196 / Re: Inliner parameters

[Richard Guenther]

On 23 Apr 2003, Steven Bosscher wrote:

> Op wo 23-04-2003, om 13:36 schreef Richard Guenther:
> >
> > 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?
>
> Part of that 30% can probably be explained with PR 8361, but inlining
> still is slower, and there should be a PR for that, I think.
>
> So I propose we close PR 10316, and we either close 10196 and open a new
> PR for the inliner slowdown, or we leave 10196 open with a remark in the
> audit trail.  Does that sound OK to you?

I assumed the inliner slowdown was resolved by marks first patch (a month
ago), and now the EH problem was solved. I propose to close the PR, as the
audit trail is already quite huge. I'll check the EH/inliner problems
seperately again and open two PRs tracking them separately, if necessary.

Richard.

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

Re: PR 10196 / Re: Inliner parameters

[Mark Mitchell]

On Wed, 2003-04-23 at 05:06, Richard Guenther wrote:
> On 23 Apr 2003, Steven Bosscher wrote:
> 
> > Op wo 23-04-2003, om 13:36 schreef Richard Guenther:
> > >
> > > 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?
> >
> > Part of that 30% can probably be explained with PR 8361, but inlining
> > still is slower, and there should be a PR for that, I think.
> >
> > So I propose we close PR 10316, and we either close 10196 and open a new
> > PR for the inliner slowdown, or we leave 10196 open with a remark in the
> > audit trail.  Does that sound OK to you?
> 
> I assumed the inliner slowdown was resolved by marks first patch (a month
> ago), and now the EH problem was solved. I propose to close the PR, as the
> audit trail is already quite huge. I'll check the EH/inliner problems
> seperately again and open two PRs tracking them separately, if necessary.

I think the submitter always has the right to close a PR they
submitted.  It's all about customer satisfaction. :-)

I've closed PR 10196; if there are more you want to open, go ahead. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: PR 10196 / Re: Inliner parameters

[Steven Bosscher]

Op wo 23-04-2003, om 17:46 schreef Mark Mitchell:
> On Wed, 2003-04-23 at 05:06, Richard Guenther wrote:
> > On 23 Apr 2003, Steven Bosscher wrote:
> > 
> > > Op wo 23-04-2003, om 13:36 schreef Richard Guenther:
> > > >
> > > > 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?
> > >
> > > Part of that 30% can probably be explained with PR 8361, but inlining
> > > still is slower, and there should be a PR for that, I think.
> > >
> > > So I propose we close PR 10316, and we either close 10196 and open a new
> > > PR for the inliner slowdown, or we leave 10196 open with a remark in the
> > > audit trail.  Does that sound OK to you?
> > 
> > I assumed the inliner slowdown was resolved by marks first patch (a month
> > ago), and now the EH problem was solved. I propose to close the PR, as the
> > audit trail is already quite huge. I'll check the EH/inliner problems
> > seperately again and open two PRs tracking them separately, if necessary.
> 
> I think the submitter always has the right to close a PR they
> submitted.  It's all about customer satisfaction. :-)
> 
> I've closed PR 10196; if there are more you want to open, go ahead. :-)

Actually, there's one more you may want to close: Like I said, PR 10316
is about "Very long compile time when exceptions enabled".  I haven't
tried but it seemed like 10196 and 10316 were duplicates.

Greetz
Steven

Re: Inliner parameters

[Richard Guenther]

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!

Richard.

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

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/