Originally posted by yotambien
View Post
Announcement
Collapse
No announcement yet.
Compiler Benchmarks Of GCC, LLVM-GCC, DragonEgg, Clang
Collapse
X
-
-
Originally posted by nanonyme View Post-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 migh have bugs or not and might slow down things or make it faster. Depends on the software.
Oh, and setting mtune after march is just stupid.
Comment
-
Originally posted by XorEaxEax View PostSpeaking 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
-
Well, despite if -O2 beats -O3 in some tests or not, -O3 IS the optimization which is supposed to optimize the best so it's obviously the one to use in a benchmark (unless you are benchmarking across all -O levels). As for -O3 being buggy, it's not from my experience nor is it supposed to be anything but stable.
Optimizations that are not considered fully working are introduced as separate flags, not into one of the -O levels. If/when they are considered stable (as in actually improving code and not introducing bugs) they are often added to certain -O levels. Some optimizations like for instance -funroll-loops have been around for ages but are not part of any -O level simply because it's very difficult for the compiler to estimate unrolling and thus there can be great gains aswell as great regressions using this optimization. (Although it's turned on by default if you use PGO in which case the compiler has enough data gathered to guarantee making good judgements).
For the absolute best results though you'd most likely need to run something like Acovea (http://www.coyotegulch.com/products/...o5p4gcc40.html) which omits the -O levels and tests all the flag combinations, but it's not very practical.
Comment
-
I quite like the graphics horizontally, looks good.
But I'd had appreciated a better choice of colors. Something of a similar tint for the GCC stuff and separate tints for the others. I found myself scrolling up/down a couple of times to check which color is which compiler a couple of times.
Comment
-
Originally posted by energyman View Postit would be more interessting compare that hand written asm with gcc generated code. Unless that is done there is no reason to turn off assembly just to create a testcase that is completely detached from reality.
While it certainly would also be interesting seeing how much better hand optimized assembly does against the code generated by these compilers it's not part of THIS benchmark. So yes, there's every reason to disable hand-optimized assembly here.
Comment
-
Originally posted by XorEaxEax View PostWell, in some tests -O3 loses to -O2, but very slightly. But this is a test from a year ago and I can't even find which version of Gcc was used, nor can I see if it was done on 32bit or 64bit. I test alot of packages routinely (Blender, p7zip, Handbrake, Dosbox, Mame etc) with -O2 and -O3 and O3 comes out on top.
What sort of differences do you get with Mame and Handbrake (I guess you mean x264 in this case)?
Comment
-
Originally posted by nanonyme View Post-mtune=native is redundant if you're using -march=native.
Originally posted by nanonyme View Post-fomit-frame-pointer breaks debuggability in x86.
Originally posted by nanonyme View Post-O3 has bugs and might slow down run-time in many cases.
Comment
Comment