[Bug c++/54710] New: moderately large tuple, with many gets, ballons compile time

[Bug c++/54710] New: moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

             Bug #: 54710
           Summary: moderately large tuple, with many gets, ballons
                    compile time
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: cppljevans@suddenlink.net


Created attachment 28274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28274
zip file containing source code, make files, make output, timing output

Using a multiple inheritance tuple implementation, and with many gets
to elements of tuple, compile time ballons from:
  0.5 * the compile time using clang

to:

  3.4 * the compile time using clang

when tuple size is 20.

The attached include a make file (suffix .mk) and the test driver
(suffix .cpp).  The time results are in the .txt files.
The time results show that as macro value LAST_LESS goes from
4 to 20, g++ compiles faster than clang, but as LAST_LESS
approaches TUPLE_SIZE, g++ slows down dramatically.

Could g++ be enhanced so that the compile times do no
increase so dramatically?

-regards,
Larry

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-25
     Ever Confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-25 17:13:09 UTC ---
Thanks.

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

--- Comment #2 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-25 17:15:29 UTC ---
The gcc compiler was downloaded from:

ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120624/gcc-4.8-20120624.tar.bz2

it was configured with the shell script:

#!/bin/bash
this_dir=`pwd`
$this_dir/../src/configure \
  --prefix=$this_dir/../install \
  --enable-languages=c++ \
  --enable-checking=assert,misc,tree,gc,rtl,runtime

and my system is:

uname -a
Linux evansl-desktop 2.6.32-41-generic #90-Ubuntu SMP Tue May 22 11:29:51 UTC
2012 x86_64 GNU/Linux

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-09-25 17:25:48 UTC ---
Well, if we are interested in the normal user experience, I guess we should
also time with --disable-checking. Not that I think it will make a big
difference..

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-26 09:05:04 UTC ---
That:

 --enable-checking=assert,misc,tree,gc,rtl,runtime

will enable very compile-time intensive internal checking.  Use
--enable-checking=release or at most the default checking options
(which are "yes").  If you compare with other compilers always use
release checking.

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

--- Comment #5 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-26 19:01:30 UTC ---
(In reply to comment #4)
> That:
> 
>  --enable-checking=assert,misc,tree,gc,rtl,runtime
> 
> will enable very compile-time intensive internal checking.  Use
> --enable-checking=release or at most the default checking options
> (which are "yes").  If you compare with other compilers always use
> release checking.

Thanks Richard.

I've downloaded:

ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120923/gcc-4.8-20120923.tar.bz2

and configured with --enable-checking=release.   As a result, the
gcc times to improve a lot; however, there's still the degredation
of the time w.r.t. clang and the macro, LAST_LESS approaches TUPLE_SIZE:

  LAST_LESS   gcc/clang times
  ---------   ---------------
          4   0.28
         16   1.15
         20   1.70

Certainly 1.70 is much better than 3.34.

A new .zip file is attached.  I don't know if this
indicates there's still a problem.

-regards,
Larry

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

Larry Evans <cppljevans at suddenlink dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28274|0                           |1
        is obsolete|                            |

--- Comment #6 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-26 19:04:14 UTC ---
Created attachment 28288
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28288
newer gcc with --enable-checking=release still shows relative performance
degradation wrt clang

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
         Resolution|INVALID                     |

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-27 09:09:59 UTC ---
Can you provide absolute compile-times alongside source complexity
(like the number of required template instantiations?).

Also you are using the compiler default optimization settings which for
CLANG is (IIRC) to do optimization and for GCC is to not do.  You might
want to try -O1 for both and/or explicit -O0 for both.

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

--- Comment #8 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-27 14:03:25 UTC ---
Created attachment 28292
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28292
with optimization set to -O1 for both gcc and clang

Shows much larger user (and elapsed) times with -O1, but still
same trend of gcc vs clang as LAST_LESS increases, i.e.
relative gcc performance degrades.

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

--- Comment #9 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-27 14:12:24 UTC ---
(In reply to comment #7)
> Can you provide absolute compile-times
The .out files show output of unix time command.
Is that not what you mean by "absolute compile-times"?
If not, could you explain how I get "absolute compile-times"?
> alongside source complexity
> (like the number of required template instantiations?).

How would you recommend I get this information?

> 
> Also you are using the compiler default optimization settings which for
> CLANG is (IIRC) to do optimization and for GCC is to not do.  You might
> want to try -O1 for both and/or explicit -O0 for both.

I've just attached another .zip file where -O1 was used.

OTOH, looking at the clang compiler command path, I see
it includes:

  /Debug+Asserts/bin/clang

which suggests it was created with some sort of runtime checks
which maybe slows it down, like the: 
 --enable-checking=assert,misc,tree,gc,rtl,runtime
does for clang.  Will investigate.

HTH.

-regards,
Larry

[Bug c++/54710] moderately large tuple, with many gets, ballons compile time

[cppljevans at suddenlink dot net]

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

Larry Evans <cppljevans at suddenlink dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28292|0                           |1
        is obsolete|                            |

--- Comment #10 from Larry Evans <cppljevans at suddenlink dot net> 2012-09-27 18:58:17 UTC ---
Created attachment 28294
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28294
with optimized clang, still with optimized gcc, both with -O1

Remade clang with make ENABLE_OPTIMIZED=1.  Clang times improved a lot.

Now, the degradation of relative performance of gcc w.r.t. clang
is more dramatic.

Still, gcc does better at low LAST_LESS, but reaches break even
at lower LAST_LESS (about 8).