Bugzilla – Bug 3304
Add optimisation flags to build system
Last modified: 2015-02-05 17:32:36
You need to
before you can comment on or make changes to this bug.
We should have a look at the new build system and add relevant optimisation
flags to it (e.g. -Os, -O3, -mtune=pentium, etc.).
For the sake of sanity, we should probably compile everything with the client
base requirements in mind. Even if we know a package is only used for the
server today, it might be used for the client in the future.
When I did the upgrade to FLTK 1.3.2 (bug 4461) and the adoptions to building
FLTK with CMake, it turned out that -O3 did not work at all: I got the very
literal pointer section (__OBJC,__cls_refs) does not have is exactly one
relocation entry for each pointer
The solution was to switch to -Os instead. I actually like -Os better than -O3.
http://www.gentoo.org/doc/en/gcc-optimization.xml says: "Using -O3 is not
recommended for gcc 4.x". Apple uses -Os. The article on
http://www.linux-mag.com/id/7574/ has done many tests (too many...?). At the
end, they say "Generally speaking, the -Os level did worse than the others",
but I'm not sure I fully agree. -Os did great in some tests. It reduces the
compile time as well.
Thus, -Os gets my vote as a standard/generic optimization flag. Then, we could
build components such as vncviewer and SSH with a few different flags and see
which one is best.
I'm growing a bit sceptical about -O3. -O2 seems to be what most people<tm> are
using, and we and other seem to be hitting various bugs with -O3. We should
consider switching to -O2 everywhere where we are currently using -O3.
As much as people bash gentoo, they make people build a lot of
software from source, and here's what they say:
> -O2 is the recommended default. -O3 is known to cause problems
> when used system-wide, so we recommend that you stick to -O2.
I also prefer -O2 over -O3, but still thinks we should consider -Os.
More benchmarks of different O levels:
We've made a minor start of this work in the form of bug 4929.
Fedora has hidden this in their %cmake and %configure macros. We should
probably do the same as it makes sure it isn't overlooked. Things that do not
use cmake or automake still needs to be manually looked at though.
Bug 4929 implements just that. Which means that what's left on this bug is to
check all the things that aren't covered by those macros. We also need a
rebuild to have the new flags take effect.