If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

-mtune=native is redundant if you're using -march=native.
-fomit-frame-pointer breaks debuggability in x86.
-O3 has bugs and might slow down run-time in many cases.

-O3 has been stable to compile with for ages, I can't recall having encountered any program that compiles with -O2 which has problems with -O3 in years. Also I haven't encountered any cases where -O3 is slower than -O2 in ages, so obviously these tests should be done with -O3, especially since that's where most of the new optimizations will end up.

Comment

-O3 has been stable to compile with for ages, I can't recall having encountered any program that compiles with -O2 which has problems with -O3 in years. Also I haven't encountered any cases where -O3 is slower than -O2 in ages, so obviously these tests should be done with -O3, especially since that's where most of the new optimizations will end up.

Comment

While these tests are great (kudos Phoronix!) it's unfortunate that they don't test some of the more advanced optimizations that has come during the later releases. While testing PGO (profile-guided optimization) would be a bit unfair since Clang/LLVM doesn't have this optimization, LTO (link time optimizations) exist in both compilers and would be an initeresting comparison. But I can understand that for practical reasons these more advanced optimizations have to be omitted. And since most people stick to -O3 I guess it's overall a fair comparison. Optimizations like PGO are mainly used by projects like Firefox, x264, emulators etc where the added performance really makes a difference.

Speaking of x264, in order to really compare the differences between the compilers on this package you really should compile it without the hand-optimized assembly (which I'm assuming you haven't since the results are so similar between all versions of gcc).

Comment

You are confused, these are 'time to compile', not performance benchmarks. Obviously it will take longer time 'to compile' with more optimizations than with fewer. But the resulting binary should be atleast as fast or most likely faster.