-mtune=core2 hard coded into CFLAGS?
Posted: 2016-02-26T12:42:30-07:00
In building binaries for mass use, it may make sense to shoot for the least common denominator hardware so the code will run most everywhere.
When building for my system, I find that building for -march=native and -mtune=<my_exact_CPU> runs vastly faster.
Indeed, I have measured a 6:1 speed boost in fully optimized code vs the binary from cybercom.net in DCRaw.exe!
Core2 is one step above Pentium << Nixon-administration-#1 era? At least it's not i386!
I find that even when I attempt to shoehorn my -MTune in with the CFLAGS, the venerable CORE2 spec succeeds mine in the actual make spew:
... -mtune=broadwell<knightslanding does not compute... :\( > -Wall -mtune=core2 ...
I can only hope GCC is smart enough to see the conflict and pick the right one.
It might be better to not make strain GCC's desperately tenuous grip on reality by forcing it to choose.
=========================================================
AND NOW, FOR SOMETHING COMPLETELY DIFFERENT, (though vaguely similar):
While we are at it, Intel recommends a bunch of compiler optimizations for GCC for the newer CPUs [GCC x86 performance hints https://software.intel.com/en-us/blogs/ ... ance-hints]
I build all my programs with "gcc -ffast-math -m64 -Ofast -march=native -fopenmp -funroll-loops -flto ... " and have found only 1 case in which I needed to drop the FullLinkTimeOpt, -flto, option to get a link.
Will these "localized sub-optimizations", as Click & Clack might have called them, melt IM?
When building for my system, I find that building for -march=native and -mtune=<my_exact_CPU> runs vastly faster.
Indeed, I have measured a 6:1 speed boost in fully optimized code vs the binary from cybercom.net in DCRaw.exe!
Core2 is one step above Pentium << Nixon-administration-#1 era? At least it's not i386!
I find that even when I attempt to shoehorn my -MTune in with the CFLAGS, the venerable CORE2 spec succeeds mine in the actual make spew:
... -mtune=broadwell<knightslanding does not compute... :\( > -Wall -mtune=core2 ...
I can only hope GCC is smart enough to see the conflict and pick the right one.
It might be better to not make strain GCC's desperately tenuous grip on reality by forcing it to choose.
=========================================================
AND NOW, FOR SOMETHING COMPLETELY DIFFERENT, (though vaguely similar):
While we are at it, Intel recommends a bunch of compiler optimizations for GCC for the newer CPUs [GCC x86 performance hints https://software.intel.com/en-us/blogs/ ... ance-hints]
I build all my programs with "gcc -ffast-math -m64 -Ofast -march=native -fopenmp -funroll-loops -flto ... " and have found only 1 case in which I needed to drop the FullLinkTimeOpt, -flto, option to get a link.
Will these "localized sub-optimizations", as Click & Clack might have called them, melt IM?