GCC 5.3 Optimization Level Tests From -O0 To -Ofast

[Guest]

OMG, the first Gentooish benchmark, is it?
gcc 5.3 is still masked, though and 4.9.3 is declared stable on amd64 Gentoo.

I personally always go with mtune/march=native, give flags like -mmmx and so on if somthing is unsure. I use -O2 cause it is known to be safe. -O3 gives faster code but might cause problems occasionally. Also I am missing -Os in this test, that one is useful for Geodes, VIA CPUs and other units of the smaller kind. -Os works for most things; though it was said in the past that wine, libreoffice (at that time still OOo) and maybe some assembler heavy things (zsnes) might not go well with it. (So I excluded these packages from any custom cflags).
So I'd say unless you want to debug generally or create a universal boot media one should use march=native all the way once you decide to compile things.

On AMD CPUs (Kaveri), -march=native usually generates some code that cannot be emulated by Valgrind. This means that "valgrind --tool=callgrind" cannot be used to profile the code.

[duby229]

Also -03 will produce strange runtime behaviour. Weird and indescribable things happen. It just does -not- produce correct code.

[sehe]

Also -03 will produce strange runtime behaviour. Weird and indescribable things happen. It just does -not- produce correct code.

File a bug with a minimized example! Chances are, a helpful analyst will point where the Undefined Behaviour is invoked

[duby229]

File a bug with a minimized example! Chances are, a helpful analyst will point where the Undefined Behaviour is invoked

Actually that sounds like a good idea. I have one example which I believe results in firefox 43 crashing to the desktop. Recompiling it with -O2 seems to have fixed that one. I feel kinda bad actually cause I made a stick about that crash problem in a different thread. oops

EDIT: I'm a Gentoo user, so I have emerge -e world running now with -O2. Once that is complete I'll recompile firefox 43 with -O3 and see if I can duplicate the identical crash problem.

[FireBurn]

I'm running with some added graphite options "-O3 -march=native -pipe -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block" and on my kabini system I'm just using "-O2 -march=native -pipe" both are with GCC 5.3 or will be as soon as the Kabini system finished compiling

[duby229]

Got that emerge -e world finished and recompiled firefox with -O3 and I'm not able to reproduce that crash bug, so my guess is that the problem never was in firefox itself, but probably in one of its dependencies? I don't know, but all is well now.,

[hubicka]

This is the traditional viewpoint but is it really true in the modern era? My SSD is 2-3 years old now but still hits over 400MiB/s with practically zero latency, is it still the bottleneck? What about new disks like the Samsung 950 that run over 2000MiB/s? Storage technology has been moving a lot faster than processors, especially in terms of latency and random reads.

-Os really is just about producing small code. I did some benchmarking on larger applications
(OpenOffice: http://hubicka.blogspot.ca/2014/09/l...cc-part-3.html )
(Firefox: http://hubicka.blogspot.ca/2014/04/l...2-firefox.html )

and it does not seem to fare better even in benchmarks that highly favour smaller binaries (such as startup times)

[Shaman666]

Where -Os should (should) shine is in binaries that are called many, many times per second and which have a minimum of linking. Such as qmail mail servers, as an example.