What is the best CFLAGS for my processor?

[pablolo]

Hello, I'm using a Pentium III Coppermine 797 Mhz.

What would be the best settings for my CFLAGS and would it really matter? I'm using the default CFLAGS:

Code: Select all

CFLAGS="-02" -march=pentium3 -fomit-frame-pointer
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

thanks

[greasy_grasshopper]

Your CFLAGS are fine. The only thing you can add to it is "-pipe", I think this will speed up compiling by not making any temporary files. Too much optimizations will break your system. I'm not really sure what's wrong with "-O3", but some people say that it's not worth it.

EDIT:typo

[Veto]

Hello, I'm using a Pentium III Coppermine 797 Mhz.

What would be the best settings for my CFLAGS and would it really matter? I'm using the default CFLAGS:

Code: Select all

CFLAGS="-02" -march=pentium3 -fomit-frame-pointer
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

thanks

I would quote the entire CFLAGS string, not just "-O2" and add -pipe.

From:

Code: Select all

CFLAGS="-02" -march=pentium3 -fomit-frame-pointer

To:

Code: Select all

CFLAGS="-02 -march=pentium3 -fomit-frame-pointer -pipe"

[rhill]

i would go one further and change -02 to -O2

[jbannon]

In general, so long as you stick to applying machine--independent optimisations such as unroll-loops and inline-funtions, GCC is pretty safe, although these two might generate big executables, but the more aggressive optimisations (> O2 and fastmath) should be avoided as they're much too brittle for general use. GCC, whilst a good compiler suite, isn't a world beater when it comes to aggressive optimisations.

[ciaranm]

In general, so long as you stick to applying machine--independent optimisations such as unroll-loops and inline-funtions, GCC is pretty safe, although these two might generate big executables, but the more aggressive optimisations (> O2 and fastmath) should be avoided as they're much too brittle for general use. GCC, whilst a good compiler suite, isn't a world beater when it comes to aggressive optimisations.

Neither loop unrolling nor inlining functions are machine independent.

[nxsty]

Your CFLAGS are fine. The only thing you can add to it is "-pipe", I think this will speed up compiling by not making any temporary files. Too much optimizations will break your system. I'm not really sure what's wrong with "-O3", but some people say that it's not worth it.

EDIT:typo

-O3 bloats your binaries and the small speed gains it gives is usually not worth it.

My flags are:

CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer -fweb -fno-ident"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fno-enforce-eh-specs"
LDFLAGS="-Wl,-O1"

[jbannon]

In general, so long as you stick to applying machine--independent optimisations such as unroll-loops and inline-funtions, GCC is pretty safe, although these two might generate big executables, but the more aggressive optimisations (> O2 and fastmath) should be avoided as they're much too brittle for general use. GCC, whilst a good compiler suite, isn't a world beater when it comes to aggressive optimisations.

Neither loop unrolling nor inlining functions are machine independent.

Huh? I hate to question a developer but can you please explain to me why they're not machine-independent? Every book on compiler design I have, and I have a few, lists these as candidates for machine-independent optimisation. For example, inlining is just macro-expansion with the difference that it follows the scope and visibility rules, guarantees that all side-effects in the arguments have taken place prior to expansion and that each argument is evaluated exactly once - no machine-dependent steps needed there. Indeed, you can do this in the source code if you're careful and the same applies with loop unrolling. Whether or not you would routinely do this during development is quite another matter. Similar optimisations can be done with arrays - no machine-dependent manipulations required to transform array indexing into pointer manipulation. All of these are certainly language-dependent and will result in different assembler output on different architectures but they can be, and typically are, performed before the back-end is even called to generate the actual target instructions. fastmath is a different matter because it relies on direct use of maths coprocessor instructions.

[ciaranm]

Huh? I hate to question a developer but can you please explain to me why they're not machine-independent? Every book on compiler design I have, and I have a few, lists these as candidates for machine-independent optimisation. For example, inlining is just macro-expansion with the difference that it follows the scope and visibility rules, guarantees that all side-effects in the arguments have taken place prior to expansion and that each argument is evaluated exactly once - no machine-dependent steps needed there.

You're forgetting register windowing. On some architectures, inlining certain things is less efficient because you've got to manually shove a load of registers onto the stack rather than just shifting windows. So a decent compiler will have special handling for architectures for which this applies.

Indeed, you can do this in the source code if you're careful and the same applies with loop unrolling.

Except that some CISC architectures have special loop handling tricks which mean you might not want to unroll certain kinds of tight loop -- a decent compiler knows about these.

Note that gcc is not always a decent compiler, however

[jbannon]

Can't disagree with that, but in principle it can be done by the front-end, usually by making appropriate adjustments to the semantic tree although techniques vary depending on what form, if any, the intermediate representation takes. Of course, when generating actual target code register windowing etc become issues, although it is difficult to see how a re-targetable front-end could deal with these efficiently.

Yeah, I know GCC isn't the best compiler suite on the planet (although the GCC boys might well disagree ) but it's still pretty good nonetheless so long as you don't overstress the optimisation. Given that it's free software it's pretty good value for money! The same might be said of KDE, but given that all the developer tools and office software come along for free and would cost the better part of £2000 on some other platforms I could mention, I'll live with the limitations.