Bug 26788 - optimization of expression templates not as performant as g++ 4.0.2
Summary: optimization of expression templates not as performant as g++ 4.0.2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.0
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, missed-optimization
Depends on:
Blocks:
 
Reported: 2006-03-21 21:06 UTC by axel
Modified: 2008-01-27 12:35 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Results file for testcase (524 bytes, text/plain)
2006-03-22 11:13 UTC, axel
Details
master shell script (253 bytes, text/plain)
2006-03-22 11:14 UTC, axel
Details
single experiment shell script (323 bytes, text/plain)
2006-03-22 11:15 UTC, axel
Details
testcase source file (23.19 KB, text/plain)
2006-03-22 11:16 UTC, axel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description axel 2006-03-21 21:06:37 UTC
Hi,

I just installed gcc 4.1.0 to compile my template expression 
matrix arithmetric library (a la Blitz). 
I recently did benchmarks with g++ 3.4.4
and 4.0.2 an I was pretty much impressed that g++ 4.0.2 managed to
optimize the expressions such that I obtained performance nearly
twice as fast as with g++ 3.4.4, and even better
the performance was the same as my hand coded pointer only implementation.
I was rather happy with this result. It seems that the handling of 
pointer arrays that are stored in a struct that represents the expression
has been significantly improved.  

Now, the downside. I tried 4.1.0 and I noticed that the performance dropped down too a level even worse than gcc 3.4.4. I wondered about the reason and 
scanned the optimization parameters. I found salias-max-implicit-fields
with a default value of 5. I guessed that might be the reason
and increased the value to 50. With this value I've got back the impressive performance of g++ 4.0.2.

I wonder why the default value has been set so low that apparently it
cripples the optimizer to a level of optimization consierably
below what has been achieved with g++ 4.0.2 (where this option does not exist).
Does this option negatively affects performance elsewhere? If not
it seems to me that a default value that resembles the 
settings in gcc 4.0.2 would be more sensible.

Kind regards,

and thanks anyway for this great compiler suite.

Axel
Comment 1 Andrew Pinski 2006-03-21 21:14:40 UTC
salias-max-implicit-fields did not exist in 4.0.x.
Comment 2 Andrew Pinski 2006-03-21 21:27:09 UTC
And the reason why salias-max-implicit-fields is set so low is to keep the compile time in check since we get bug reports about that also.
Comment 3 Andrew Pinski 2006-03-21 21:28:50 UTC
Also do you have a testcase that can be attached to the bug since the information here is not enough to figure out what is going wrong.
Comment 4 Richard Biener 2006-03-22 09:12:21 UTC
If the salias-max-implicit-fields setting helps you then this is a PTA issue.  I never hit PTA issues with the expression templates in POOMA, so it might be interesting to get a testcase for this.  A testcase is also necessary to do anything about it.
Comment 5 axel 2006-03-22 11:13:48 UTC
Created attachment 11090 [details]
Results file for testcase

As you requested I provide a testcase. It consists of 2 shell scripts
that run the different compilers and then run the testcase.
The testcase has two cases and two compilation modes:

switch 1
compiled with -DHAND it gives hand optimized pointer only version
compiled with -DMATMTL it gives the equivalent expression templates version
switch 2
compiled with -DBENCH=1 it calculates an addition of three vectors
compiled with -DBENCH=2 it calculates an addition of three vectors with some scalar multiplications

The name of the excutable will indicate the experiment by two final characters H1 stands for hand optimized first benchmark, M2 stands for matmtl second benchmark ...

The two scripts comp.sh and master.sh run the whole experiment:
comp.sh runs the experiment for a single compiler and a user supplied set of  vector sizes. Note, that each experiment always uses 100000000
vector element operations. By means of the vector size the amount of overhead can be controlled.
master.sh runs comp.sh with a single compiler and the vector size arguments 5 and 1000

Results are produced with

./master.sh 2>&1 | tee mout
egrep "#|user"  mout

First result is that gcc 4.1.0 with --param  salias-max-implicit-fields=50
is a real success. As you see the compile time does not change "at least for this testcase" but the performance is identical to the pointer only
case!!!!!!!!!!!!!!!!!!!!

second result is that for gcc 4.1.0 with default parameter set
we get performance worse then gcc 4.0.2 especially for small vectors
(large overhead). The larger the vectors become the more
gcc 4.1.0 approaches 4.0.2

###############################################################
# g++ 4.0.2 the reference
###################################################
#compile times
user    0m0.702s
user    0m0.697s
user    0m1.066s
user    0m1.077s
#run times : vector size 5
# benchmarkredH1
user    0m0.295s
# benchmarkredM1
user    0m0.307s
# benchmarkredH2
user    0m0.381s
# benchmarkredM2
user    0m0.412s
#run times : vector size 1000
# benchmarkredH1
user    0m0.230s
# benchmarkredM1
user    0m0.243s
# benchmarkredH2
user    0m0.287s
# benchmarkredM2
user    0m0.370s
# g++ 4.1.0 default
###################################################
#compile times
user    0m0.747s
user    0m0.752s
user    0m1.211s
user    0m1.227s
#run times : vector size 5
# benchmarkredH1
user    0m0.264s
# benchmarkredM1
user    0m0.519s
# benchmarkredH2
user    0m0.347s
# benchmarkredM2
user    0m1.211s
#run times : vector size 1000
# benchmarkredH1
user    0m0.222s
# benchmarkredM1
user    0m0.286s
# benchmarkredH2
user    0m0.298s
# benchmarkredM2
user    0m0.375s
# g++ 4.1.0 salias=50
###################################################
#compile times
user    0m0.753s
user    0m0.741s
user    0m1.225s
user    0m1.239s
#run times : vector size 5
# benchmarkredH1
user    0m0.262s
# benchmarkredM1
user    0m0.307s
# benchmarkredH2
user    0m0.344s
# benchmarkredM2
user    0m0.313s
#run times : vector size 1000
# benchmarkredH1
user    0m0.223s
# benchmarkredM1
user    0m0.234s
# benchmarkredH2
user    0m0.299s
# benchmarkredM2
user    0m0.260s
Comment 6 axel 2006-03-22 11:14:47 UTC
Created attachment 11091 [details]
master shell script

for comments 
see 11090: Results file for testcase
Comment 7 axel 2006-03-22 11:15:43 UTC
Created attachment 11092 [details]
single experiment shell script

for comments 
see 11090: Results file for testcase
Comment 8 axel 2006-03-22 11:16:19 UTC
Created attachment 11093 [details]
testcase source file

for comments 
see 11090: Results file for testcase
Comment 9 Richard Biener 2006-03-22 11:39:31 UTC
This is another case of find_used_portions missing explicit uses due to C++ and
lots of inlining without any cleanup after that.  And inserting cleanup being difficult because structure-aliasing pass running before going into SSA.  A forwprop pass before it would do wonders here.

Danny - any plans to look at making salias pass work on SSA form?  With inlining
on SSA like on IPA branch this looks necessary anyway (Honza simply moved the
pass to before (final) inlining, which will make the situation just worse).
Comment 10 axel 2006-03-22 11:55:05 UTC
Not that I understand what you just said, but, I wanted to mention, that 
in contrast to my initial email the data I just sent
indicates a small performance penalty  of about 25% for g++ 4.0.2 
for large vectors on a pentium 4 (that are the results I've sent) 
while there is no such 
penalty for large vectors on a pentium m. On a pentium m g++ 4.0.2
works as well as g++ 4.1.0 on pentium 4 with the --param salias...=50.
Unfortunately, I dont have gcc 4.1.0 on my pentium m machine

thanks,

Axel
Comment 11 Andrew Pinski 2006-04-30 04:11:14 UTC
(In reply to comment #9)
But that only applies to 4.2 and not 4.1.0.
Comment 12 Richard Biener 2008-01-26 22:58:34 UTC
Can you check 4.2 and 4.3?
Comment 13 axel 2008-01-27 12:35:35 UTC
Hi,

I run the tests with g++ 422 and it seems to  me the issue is closed.
Compilation without the salias-max-implicit-fields flag is nor producing
any substantial increase in run time any more and with and without
this parameter the hand optimized and compiler template version 
of the code have very similar run time.

I would be really happy with this, if gcc422 would produce
correct code in all my projects. I tried it already a while ago
and found a problem with std::set where the optimized version of the program simply did and up with duplicate entries in the set 
(while gcc 4.1.2 has no problems with the very same code)!!!

Besides that show stopper we had other problems with code using
sse/sse2 intrinsics  producing wrong results when optimization was enabled.

All this may have changed in gcc4.3. I will give it another trial.

Thanks