[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #17 from bfriesen at simple dot dallas.tx.us 2012-07-21 01:04:55 UTC --- I discovered that GCC's __attribute__((__optimize__())) and optimization pragmas do not work for OpenMP code because OpenMP uses a different function name for the actual working code. This makes it much more painful to work around this bug.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #16 from bfriesen at simple dot dallas.tx.us 2012-07-19 14:29:10 UTC --- Is there a way that I can selectively apply the -frename-registers fix to functions which benefit from it in order to work around the bug until the fix is widely available? I tried #pragma GCC optimize (O3,rename-registers) and #pragma GCC optimize (rename-registers) as well as the function attribute equivalent and there was no effect. GCC seems to ignore the request. I did find another somewhat similar function which benefited significantly from -frename-registers.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #14 from bfriesen at simple dot dallas.tx.us 2012-07-18 14:28:04 UTC --- With -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O2 -funroll-loops -fschedule-insns I see a whole-program performance jump from 0.047 iter/s to 0.156 iter/s (331% boost). That is huge! Given the fundamental properties of this algorithm (the image processing algorithm most often recommended to be moved to a GPU) the world would be a better place if this performance was the normal case. With -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O2 -fschedule-insns I see 0.101 iter/s These must not be included in -O3 since -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O3 produces only 0.048 iter/s
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #15 from bfriesen at simple dot dallas.tx.us 2012-07-18 20:42:22 UTC --- Testing shows that using -m64 -march=native -O2 -mfpmath=sse -frename-registers is sufficient to restore good performance.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #8 from bfriesen at simple dot dallas.tx.us 2012-07-16 14:16:46 UTC --- I used -march=native in this case. It is interesting that this enabled AVX (this particular CPU does support it). To be clear, the problem also occurs with -m64 -mtune=generic -march=x86-64 -mfpmath=sse vs -m64 -mtune=generic -march=x86-64 -mfpmath=387 and is also observed on a 5-year old Opteron. With GCC 4.7.1, and for a specific application benchmark case and with generic architecture and tuning, -mfpmath=387 produces 0.133 iter/s and -mfpmath=sse produces 0.047 iter/s. A different (non-GCC) compiler on the same system produces 0.155 iter/s. In the course of testing, I have indeed tried -march=corei7 and it did not provide an improvement.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #10 from bfriesen at simple dot dallas.tx.us 2012-07-16 15:35:03 UTC --- This particular application test was done with these options (i.e. -O2): -m64 -mtune=generic -march=x86-64 -mfpmath=387 -O2 I have also tried -O3, with no positive benefit. The Autoconf default is -O2 so that is what I generally test/tune the software with. It is pretty rare to see additional benefit from -O3, although with some versions of GCC I have seen application crashes due to wrong code from the tree vectorizer. Bob
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #11 from bfriesen at simple dot dallas.tx.us 2012-07-16 15:41:08 UTC --- I just verified that -O3 produces similar timings to -O2 for both -mfpmath=387 and -mfpmath=sse
[Bug c/53967] New: GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 Bug #: 53967 Summary: GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default) Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bfrie...@simple.dallas.tx.us Created attachment 27792 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27792 Convolution example C file, pre-processed version, build log, assembler output The classic convolution algorithm (as implemented in GraphicsMagick) is observed to run 2X slower with -mfpmath=sse than with -mfpmath=387. Unfortunately -mfpmath=sse is the default for -m64 builds on AMD_64 so this has large impact for users. Even with -mfpmath=387 other compilers (LLVM, Open64, and Oracle Studio) produce faster code by default so some of these compilers are producing up to 3X better overall run-time performance and all of them are at least 2X faster than the GCC default for x86-64. This issue has been verified under Solaris 10, OpenIndiana, and Ubuntu Linux on Opteron and several modern Xeon CPUs. Please note that AMD Opteron 6200 family CPUs were not observed to suffer from this issue.
[Bug c/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #1 from bfriesen at simple dot dallas.tx.us 2012-07-14 20:55:48 UTC --- Created attachment 27793 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27793 Build log
[Bug c/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #2 from bfriesen at simple dot dallas.tx.us 2012-07-14 20:56:55 UTC --- Created attachment 27794 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27794 Sample portable source file
[Bug c/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #3 from bfriesen at simple dot dallas.tx.us 2012-07-14 20:57:58 UTC --- Created attachment 27795 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27795 Pre-processed source
[Bug c/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #4 from bfriesen at simple dot dallas.tx.us 2012-07-14 20:58:59 UTC --- Created attachment 27796 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27796 Generated assembler code
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #5 from bfriesen at simple dot dallas.tx.us 2012-07-14 21:06:27 UTC --- Please note that while I mentioned GCC 4.6.2, the same problem is also observed with GCC 4.7.1.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #6 from bfriesen at simple dot dallas.tx.us 2012-07-14 21:42:38 UTC --- Created attachment 27797 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27797 Pre-processed GraphicsMagick source (effect.c). In case the small sample (which only illustrates the core algorithm) does not satisfy, I have attached a pre-processed version of the real GraphicsMagick code with the performance issue. Look for ConvolveImage().
[Bug bootstrap/35531] Assembler failure while compiling libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35531 bfriesen at simple dot dallas.tx.us changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #14 from bfriesen at simple dot dallas.tx.us 2010-12-09 01:41:25 UTC --- (In reply to comment #13) Since I have had successful builds of both 4.5.x and 4.6.x of gcc using current GNU binutils (2.20.1.x) and Sun ld, can this bug be closed? Yes, this bug can be closed. I am using GCC 4.4.4 with GNU as and the Sun ld with no problems: % gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /home/bfriesen/src/gnu/gcc-4.4.4/configure LDFLAGS='-L/usr/local/lib -R/usr/local/lib' --program-suffix=-4.4.4 --enable-shared --enable-threads --enable-version-specific-runtime-libs --with-gnu-as --with-as=/usr/local/lib/binutils-2.20/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-cpu=opteron --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.4 (GCC) Bob
