Heard from someone that it's possible to compile software from source and play with gcc flags to increase performance comparing with pre-comiled binaries... is it true?

as far as i know, re-compiling kernel with suitable options that match your needs and hardware would speed up the system and shrink down the size of the binaries and i can learn some of its techniques in books like O'Reilly understanding linux kernel... but how about other software such as firefox? I use mac mainly and people's been going firebox optimized for G4 and things like that and i'd like to learn but don't know where to start with..

contrary to popular belief size of the binaries and speed are often not in any way the same thing..
Linux and GNU programs in particular are optimized for speed not size..
But with the kernel like you said just eliminating stuff you don't use is a different story.
Todays processors have some very deep pipes that can handle things like urolled loops which are larger and faster. (don't know about motorola cpus) Also binaries can be sripped of debugging symbols for size but contrary to popular belief this has no effect on the amount of symbols loaded at runtime. This may effect scan time in some way however looking for symbols.

So anyway yes you can increase the perfomance of you machine greatly with compiler flags but do lots of benchmarking first to decide what flags to use and realize alot of what you read on the internet about this is just mythology.

When you compile the kernel you have to hack the Makefile to add the gcc flags and get verbose output so you can see the exact effect of what you are doing. The kernel takes well to agressive optimizations.

Some other programs if you use agressive optimizations end up broken and unstable
(both Firefox and X where broken by optimizations on my machine)

also never try to optimize the core like gcc itself or glibc.

have fun

see here (assuming your running an x86 or x86_64 architecture )
for details on what options you can pass. But be warned, as foo_bar_foo stated above, if you try to over do it you may end up with a program that behaves oddly/crashes regularly. to set the flags do:
So for example if you wanted to optimize for your processor ( which we'll assume is an athlon-xp for this example):


the -mcpu options tells the compiler to optimize for the athlon-xp but allow older processors to still run the code. The -march option tells the compiler to fully optimize the code for the athlon-xp, but to the point where athlon-xp is the minimum processor which will run the code.

You will have to experiment with different options to see what you like best. My personal opinion is stick with light optimizations ( like -mcpu and such ) as the more you throw in, the less stable things tend to become. Also, the perfomance gain isn't exactly night and day either. You may get a touch more responsiveness ( this is debatable) but overall ( In my opinion ) its not worth recompiling your whole system over to try to get better performance.

ps - if your compiling c++ code, you'll have to set CXXFLAGS too like this (assuming you have set CFLAGS like above):

http://gcc.gnu.org/onlinedocs/gcc-3....002d64-Options

Although, to note: you probably will not see much of (if any) a NOTICEABLE speed increase.
See also: Gentoo
And this thread here:
http://episteme.arstechnica.com/eve/...m=811002048631

Some applications really do benefit greatly from being built with options specific to your hardware - mplayer for example.


Håkan

I may not be optimizing as aggressively as you, but my own Firefox build, optimized for Pentium 4 / SSE-2 using -O3 and a few other flags, runs well on my Linux box.

this is interesting and an indicator of how complex it can all get
i had to take away even the default optimizations or i got the loop thing at startup even as root..
what you said implies it's because i optimized other underlying libs.

In my opinion, as long as you stick to modest optimizations, like the O flag and cpu optimizations, you'll be alright. But in my experience, trying to throw too many flags into it will break some code. And it also depends on the flags themselves, as optimizing for a pentium 4 gcc will do completely different things than if had optimized for an athlon-xp or something else.

This discussion leaves me wondering what optimization is all about. After all, all the source code is written in grammatically correct language (be it C or Java or whatever else) by definition; otherwise it would not even compile. Yet optimizing that grammatically correct code may break something - to me, that can only mean a bug (or bugs) in the compiler.

I remember the flag "-match=pentium4" did not work with GCC 3.2.x when I compiled Firefox with it. The binary was built, but it would not run. The exact same flag now works with GCC 3.3.x.

I don't think it's a bug, I mean when you optimize moderately, chances are you'll never have any problems.
But when you start throwing some of these in at random, you could break the build ( especially if the programmer used things which were not illegal, but not technically correct either like depending on sizes of structs, manipulating pointers in unintended ways, etc...). Note that some of those options above when given to gcc will tell gcc to break the ANSI standard if it has to..

daihard, those are features - not bugs.

Yeah, it's a common sarcastic expression but this time I actually mean it. The optimization flags passed to gcc do not really have anything to do with the code itself. They control the way gcc handles different operations - like unrolling loops to save a few cpu cycles but spend a few more cpu registers.

The flags differ between different versions of the gcc compiler, and CPU types are constantly added or altered: The AMD processor family formerly known as "k8" is now referred to as "athlon-4" in gcc 3.3.5, and so on.


Håkan

I know what you guys are saying, but when it gets right down to business, my opinion is that the compiler should not attempt to optmize the code in a way that may break the resulting binary, no matter how badly the source is written.

I am a C programmer, so I know it's very easy to abuse the C language. However, most of the modern C compilers are able to give you warning about bad, if not illegal, code (such as using pointers interchangeably with non-pointer data types). I agree with you that code full of such warnings may result in non-working binaries if optimized aggressively, but clean code should always be built to run - whether or not optimized. In my opinion, anyway.

(But again, I know it's not too hard to fool the compiler to give you no warnings using explicit casts and other things...)

As for the "-march=pentium4" flag, it was present with GCC 3.2. It just did not work as intended, at least when I built Firefox.

i disagree with this
i use a very basic non-esoteric benchmark as an example

on my machine with -O flag
10 second file copy 63787KBps
with -march=pentium4 -O3 -funroll-loops -ftracer -momit-leaf-frame-pointer -fprefetch-loop-arrays
10 second file copy 71242KBps

that's what -- a little over 11.5% increase on a basic simple operation

wow that would mean just one compiler that compiles things only one way..
(lost in 1982 forever no matter where the hardware goes)
then you just pretend like the code is good just cause you can get it to compile (aka Micr$ft)..

sometimes the compiler has bugs but more often then not it's the code with bugs and design problems that are being brought out by the optimizations and are hiddden otherwise..

so code should be tested on all kinds of equipment and with all kinds of optimizations and even be tested on different compilers to weed out the funky stuff.

you cold turn this around and say -- no matter how badly the compiler is written no code should be written so it breaks when optimized for certain architectures.

Well, i dont know if it's true or not, but for me, although i compile mplayer 4 times with many options (-gui, -crash-debug, cpuruntime-detection, --enable-dvdread) it still crash whenever i play dvd from dvd+rw !!!!