[Bug c++/16703] New: g++ v3.5.0 produces slower code than v3.4.1 for loops.

[Bug c++/16703] New: g++ v3.5.0 produces slower code than v3.4.1 for loops.

[godaves at yahoo dot com]

g++ v3.5.0 produces slower code than v3.4.1 for some loop-intensive algorithms.
Also, the fomit-frame-pointer switch seems to act as a "de-optimization" switch
for some of the attached code (unlike v3.4.1, for which the fomit-frame-pointer
switch seems to make for faster executables for most applications).

-- 
           Summary: g++ v3.5.0 produces slower code than v3.4.1 for loops.
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P1
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: godaves at yahoo dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug c++/16703] g++ v3.5.0 produces slower code than v3.4.1 for loops.

[godaves at yahoo dot com]

------- Additional Comments From godaves at yahoo dot com  2004-07-25 04:49 -------
Created an attachment (id=6824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6824&action=view)
Source code, -save-temps output, timings and configuration info.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [3.5 Regression] g++ v3.5.0 produces slower code than v3.4.1 for loops.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-25 05:39 -------
First off what is the full version of gcc aka what is the date on the compiler?
Second next time say what target this is because gcc supports many and on some 3.5.0 is faster 
already than 3.4.x.

For both of these giving the output of gcc -v will do.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |regression
 GCC target triplet|                            |i686-pc-linux-gnu
           Keywords|                            |missed-optimization
            Summary|g++ v3.5.0 produces slower  |[3.5 Regression] g++ v3.5.0
                   |code than v3.4.1 for loops. |produces slower code than
                   |                            |v3.4.1 for loops.
   Target Milestone|---                         |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [3.5 Regression] g++ v3.5.0 produces slower code than v3.4.1 for loops.

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2004-07-25 12:35 -------
Well, those benchmarks are highly artificial, and therefore of doubtful
value. They certainly also don't all measure the same thing. Moreover, if
you're interested in loop performance, you should really try the lno branch,
since that is the only place where loop work is going on. It already brings
some progress, for example "nestedloop" is about 746 times faster :-)

I suggest you retry with lno-branch, and then single out benchmarks which
shows really noticeable (say, >50%) regression.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [3.5 Regression] g++ v3.5.0 produces slower code than v3.4.1 for loops.

[godaves at yahoo dot com]

------- Additional Comments From godaves at yahoo dot com  2004-07-25 15:18 -------
(In reply to comment #1)
> Created an attachment (id=6824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6824&action=view)
> Source code, -save-temps output, timings and configuration info.
> 

That information is in the attached tarball.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [3.5 Regression] g++ v3.5.0 produces slower code than v3.4.1 for loops.

[godaves at yahoo dot com]

------- Additional Comments From godaves at yahoo dot com  2004-07-26 00:13 -------
(In reply to comment #3)
> Well, those benchmarks are highly artificial, and therefore of doubtful
> value. They certainly also don't all measure the same thing. Moreover, if

The point of the report and the simple code submitted with it is to hopefully
provide the code-gen team with some low-hanging fruit to determine the reason
for the lower performance, especially given that SSA/GENERIC/GIMPLE has been
mainlined in 3.5.0.

Granted, the differences aren't that great but the performance does regress a
bit for this trivial code, at least with the 20040718 build, so I think the
heads-up is prudent.

I'll give it a shot with the 20040725 build that just became available as well,
when/if I get the time.

> you're interested in loop performance, you should really try the lno branch,
> since that is the only place where loop work is going on. It already brings
> some progress, for example "nestedloop" is about 746 times faster :-)
> 
> I suggest you retry with lno-branch, and then single out benchmarks which
> shows really noticeable (say, >50%) regression.

Since computers spend a great deal of their time looping, I'm very interested in
loop performance. And if you have some benchmarks in mind, don't hesitate to
pass them along.

When is the lno-branch due to be mainlined?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|                            |20040718


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [4.0 Regression] g++ v4.0.0 produces slower code than v3.4.1 for loops.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-17 03:55 -------
most of the lno has been merged already, can you try again?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [4.0 Regression] g++ v4.0.0 produces slower code than v3.4.1 for loops.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-21 14:32 -------
Here is the results on powerpc-darwin for Apple's 3.3 and an almost new mainline:
Machine Info
--------------------
kernel       : 7.4.1
Tool Info
--------------------
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
--------------------

3.3/temp contains compiler output from the '-save-temps' switch

results
--------------------
ackermann 13: ack(3,13): 65533 515.266 seconds (omit-frame-pointer)
ackermann 13: ack(3,13): 65533 492.83 seconds (with-frame-pointer)
hash2 3000: 1 9999 3000 29997000 9.48383 seconds (omit-frame-pointer)
hash2 3000: 1 9999 3000 29997000 10.2518 seconds (with-frame-pointer)
heapsort 10000000: 0.9999928555 34.5854 seconds (omit-frame-pointer)
heapsort 10000000: 0.9999928555 31.9553 seconds (with-frame-pointer)
nestedloop 45: 729000000 9.95707 seconds (omit-frame-pointer)
nestedloop 45: 729000000 12.278 seconds (with-frame-pointer)
random 300000000: 92.485425240 18.6898 seconds (omit-frame-pointer)
random 300000000: 92.485425240 18.4003 seconds (with-frame-pointer)
sieve 100000: Count: 1028 8.91343 seconds (omit-frame-pointer)
sieve 100000: Count: 1028 11.2786 seconds (with-frame-pointer)


----
Machine Info
--------------------
kernel       : 7.4.1
Tool Info
--------------------
Reading specs from /Users/pinskia/local/lib/gcc/powerpc-apple-darwin7.4.1/4.0.0/specs
Configured with: /Users/pinskia/src/local/gcc/configure --prefix=/Users/pinskia/local --enable-
languages=c,java,objc,f95 --disable-werror
Thread model: posix
gcc version 4.0.0 20041017 (experimental)
--------------------

4.0.0/temp contains compiler output from the '-save-temps' switch

results
--------------------
ackermann 13: ack(3,13): 65533 202.369 seconds (omit-frame-pointer)
ackermann 13: ack(3,13): 65533 227.047 seconds (with-frame-pointer)
hash2 3000: 1 9999 3000 29997000 9.09942 seconds (omit-frame-pointer)
hash2 3000: 1 9999 3000 29997000 9.13645 seconds (with-frame-pointer)
heapsort 10000000: 0.9999928555 37.7239 seconds (omit-frame-pointer)
heapsort 10000000: 0.9999928555 34.8575 seconds (with-frame-pointer)
nestedloop 45: 729000000 14.157 seconds (omit-frame-pointer)
nestedloop 45: 729000000 15.402 seconds (with-frame-pointer)
random 300000000: 92.485425240 6.88415 seconds (omit-frame-pointer)
random 300000000: 92.485425240 6.97493 seconds (with-frame-pointer)
sieve 100000: Count: 1028 11.6892 seconds (omit-frame-pointer)
sieve 100000: Count: 1028 10.4483 seconds (with-frame-pointer)


As you can see that we do much better on the mainline for ackermann and random but worse on 
nestedloop

So this might be able to close now as we have two progressions and one regression.  And the one 
regression is an artificial testcase:
        x = 0;
            for (int a=0; a<n; ++a)
                    for (int b=0; b<n; ++b)
                            for (int c=0; c<n; ++c)
                                    for (int d=0; d<n; ++d)
                                            for (int e=0; e<n; ++e)
                                                    for (int f=0; f<n; ++f)
                                                            x++;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703

[Bug regression/16703] [4.0 Regression] g++ v4.0.0 produces slower code than v3.4.1 for loops.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-27 00:16 -------
Fixed with the current mainline I get 
 1.4937

on the nestedloop test now.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703