[SOLVED]newer gcc version tends to generate faster binaries?

[rudregues]

Yesterday I upgraded my gcc in gentoo. But I was thinking... newer gcc versions correct bugs and improve debugging features, but is there any trends to generate faster binaries than old versions? But, to upgrade gcc we need to use an oldest version for compile and generate the gcc binarie, a little confusing this. Another question I have is if the compile time is related to the version, the newer should take more time to compile since has more features or less time since it is (or should be) a faster binarie?
_________________
Emerging en gentoo

[Logicien]

The Gcc size as a binary executable depend on the features it have. Those features are set by the USE flags in all versions. One thing you can do is to compile a new version of Gcc with the precedent version, check the binary size and than recompile that same new version with it's own version and compare the size. You can also compare the size between two versions.

The binary size is not the only thing that speed the execution of a binary, but it can give you and idea of what appen from a version to an other with the same features. Gcc gcc-4.7.3-r1 and gcc-4.8.1-r1 have the same available USE flags.
_________________
Paul

[NeddySeagoon]

rudregues,

The gcc build system is a bit of an oddball among build systems. You don't actually use the old gcc to build the new one but its not obvious.

The build system builds the new gcc, for C only with whatever random compiler you have.
This new C only gcc is used to build itself, still for C only.
Lastly, this self built gcc is used to build the gcc taht will be installed on your system.

So gcc builds parts of itself three times in the course of emerging gcc.
If all goes well, builds 2 and 3 of gcc (just the C part) should be identical. The build system does this check and fails if they are not.
This means that the gcc you have installed was actually build with the gcc you have installed now - and it was tested.

There are several speed related issues. There is the speed at which gcc produces its results and the speed of the code produces for other programs.
Its very difficult to generalise. New features are made to work first and often speeded up in later versions. More features may mean more optimisation passes but only if they are enabled.
There is a trade off here. More optimisation passes take longer, more memory, or both but produce leaner binaries.
Read up about link time optimisation (LTO) which may be usable in gcc 4.8.x. It breaks some things in 4.7.x
Thats the new feature now.

gcc has lots of flags that control how it works, some simple ones.
-O0 is fast for gcc to run but the code is slow as optimisation is turned off.
-O1 is a little slower to run but produces faster binaries.
-O2 is slower again to run but should produce faster code again as it enables all the optimisations that do not produce larger binaries.
-O3 is yet slower to run and allows gcc to produce bigger binaries in an attempt to make the code faster.

-O3 is known to break some package. Some ebuilds turn it off.
Also it can make the resulting binary much slower, as the working set may no longer fit in the CPU cache. This varies from CPU to CPU and package to package.
When the working set no longer fits in the CPU cache, many more much slower main memory reads are required, so execution slows down.
If you want to see how effective your CPU cache is, go into the BIOS and turn it off. Now try to use your system.
Thats what -O3 is like at its very worst.
Don't forget to turn your CPU cache back on.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.