CFLAGS Central (Part 1)

Message

Bobrepuss · Post by **Bobrepuss** » Tue Apr 05, 2005 12:28 pm

Heres my make.conf

CFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer"
CHOST="i386-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

Would i see any performance gain in games ( specifically under cedega) if i recompiled with better cflags?
Im running an AthlonXP (barton)

moocha · Post by **moocha** » Tue Apr 05, 2005 12:34 pm

Yes. Especially if you change your make.conf C(XX)FLAGS to read:

Code: Select all

CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -momit-leaf-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"

You also have to recompile everything after that, in theory. Specifically, you should recompile the toolchain twice, via

Code: Select all

emerge -e system
emerge -e system

However, your CHOST is wrong. Why did you change it to i386-pc-linux-gnu? It should have been i686-pc-linux-gnu instead. Changing it is not supported, and as the installation handbook points out in bold and with a red background, it should not be done at any time except when installing from stage 1, right before bootstrapping. Gremlins are known to infest your system if you do (read: expect very subtle and mysterious bugs).
Sorry, you're on your own there.

Bobrepuss · Post by **Bobrepuss** » Tue Apr 05, 2005 12:41 pm

Doh,

How badly is that impacting performance? I dont fancy starting out again :-/
But ill make the cflag changes, thanks for the advice

moocha · Post by **moocha** » Tue Apr 05, 2005 12:50 pm

The performance impact of not having the proper -march is significant, in that you can actually feel it. The most important speedup comes from recompiling glibc so you could get away with just that.
But if you're not very far into the installation, I emphatically recommend starting again, from stage 3, and not changing the CHOST setting. I wasn't kidding, you can expect all sorts of weird toolchain bugs later on with the wrong CHOST setting. Some people claim that they didn't have any problems, but I consider that pure luck (which will run out eventually).
Your call.

Bobrepuss · Post by **Bobrepuss** » Tue Apr 05, 2005 1:06 pm

Im recompiling system now with the cflags you recommended I will leave it at that for now, thanks for the help

One last thing, how long is this going to take, XP2600 with emerge -e system?

moocha · Post by **moocha** » Tue Apr 05, 2005 2:08 pm

No idea, shouldn't take more than 4-5 hours though. If the X Windows server gets pulled in by system (which can happen if you overrode some defaults) then it may take longer. That's not the typical case though.
See http://www.gentoostats.org for some build times.

Bobrepuss · Post by **Bobrepuss** » Tue Apr 05, 2005 2:26 pm

just incase others try that link there is a dash http://www.gentoo-stats.org/

thanks

*Finished recompiling once, going to go again overnight

ingvildr · Post by **ingvildr** » Wed Apr 13, 2005 5:48 pm

i was reading the wiki and it said dont use -fomit-frame-pointer if u dont have much RAM i have 256 think thats enough?

moocha · Post by **moocha** » Wed Apr 13, 2005 7:00 pm

ingvildr wrote:i was reading the wiki and it said dont use -fomit-frame-pointer if u dont have much RAM i have 256 think thats enough?

That's more than enough, and if the Wiki you mentioned said that, it's either wrong, confused, or you misunderstood. -fomit-frame-pointer does not place any significant additional RAM requirements on the compiler.

ingvildr · Post by **ingvildr** » Wed Apr 13, 2005 7:14 pm

this from gentoo-wiki.com

Code: Select all

-fomit-frame-pointer
This flag is very good if you are concerned mainly with execution times. However, binary size will almost certainly increase, sometimes by %30 or more. Do not use it on a low-space system, or one without much RAM.

stonent · Post by **stonent** » Wed Apr 13, 2005 7:16 pm

I always thought fomit-frame-pointer made things smaller by removing some debug information and this an overall optimization of size and speed.

moocha · Post by **moocha** » Wed Apr 13, 2005 7:26 pm

ingvildr wrote:this from gentoo-wiki.com

Code: Select all

-fomit-frame-pointer
This flag is very good if you are concerned mainly with execution times. However, binary size will almost certainly increase, sometimes by %30 or more. Do not use it on a low-space system, or one without much RAM.

And this is why you shouldn't blindly trust a Wiki.

stonent wrote:I always thought fomit-frame-pointer made things smaller by removing some debug information and this an overall optimization of size and speed.

It sometimes makes the generated code smaller and sometimes bigger.
The reason for the confusion is that people don't understand how compilers work and state opinions as if those opinions were fact.
-fomit-frame-pointer frees up in certain circumstances an additional register for use in the register allocator. That's it. What the register allocator does with it, whether it chooses to use it, whether the additional registers causes the machine code byte stream to be larger or smaller, what code finally gets output by the code generator - all these depend a lot on the source code, on the compiler version, and on the other active optimization flags. Any blanket statement such as "-fomit-frame-pointer makes code bigger" is hence inherently wrong...
-fomit-frame-pointer usually causes the generated code to be a bit bigger. Keyword "usually". The difference percentage may be 30% for extremely small programs, such as a "Hello, world" application, but it gets smaller as the actual executable grows. Overall, it may lie around 2-3% for a typical desktop system. And a binary that's bigger doesn't necessarily mean it takes up more RAM - there are a lot more factors involved, such as the level 2 cache size, the amount of code that actually sticks around in RAM, the typical usage for that binary (it's no big deal if an executable is bigger if it only gets run once in a while, but for a daemon it is a big deal), and about a hundred other things.
The only systems I can imagine that wouldn't benefit from using -fomit-frame-pointer are handhelds, PDAs, and so on. And it's unlikely someone will use Gentoo on such a system right now

.
I heartily recommend to use -fomit-frame-pointer on a desktop system. It's one of the few flags that cause no known ill side effects and improve performance with little cost in compile time.

elyre_elan · Post by **elyre_elan** » Tue Apr 19, 2005 7:09 pm

Back to CHOST, moocha, you agree with the documentation and state to not change the CHOST outside of stage1. I just did that for a web server (home use) that I was converting from the 2.4 kernel to 2.6. It is a low end Athalon 600 MHz. I changed the CHOST setting from 386 to 686. I am now recompiling everything.

If the machine tanks, that's fine. I can easily rebuild it. However, I am curious. If I re-compile everything (which I am doing because of nptl anyway), shouldn't that drastically reduce the number of potential bugs? Also, isn't it safer to move up (i.e. 386 to 686) vs. down due to backwards compatibility of instruction sets?

Or am I merely being naive and overly optimistic here?

Where could I find more information on what exactly CHOST does internally?

moocha · Post by **moocha** » Tue Apr 19, 2005 8:52 pm

elyre_elan wrote:Back to CHOST, moocha, you agree with the documentation and state to not change the CHOST outside of stage1. I just did that for a web server (home use) that I was converting from the 2.4 kernel to 2.6. It is a low end Athalon 600 MHz. I changed the CHOST setting from 386 to 686. I am now recompiling everything.

If the machine tanks, that's fine. I can easily rebuild it. However, I am curious. If I re-compile everything (which I am doing because of nptl anyway), shouldn't that drastically reduce the number of potential bugs? Also, isn't it safer to move up (i.e. 386 to 686) vs. down due to backwards compatibility of instruction sets?

Or am I merely being naive and overly optimistic here? Where could I find more information on what exactly CHOST does internally?

CHOST is used, among other things, by the GNU autotools (the autoconf - automake - libtool family) and the configure and linker scripts produced by these. If you change the CHOST and don't re-bootstrap (nope, recompiling everything doesn't count as bootstrap) things will break in very subtle and mysterious ways later. If you change the CHOST and re-bootstrap, things may break later, but the potential for breakage is far less. Doesn't actually matter much in which direction you change the CHOST.

codergeek42 · Post by **codergeek42** » Tue Apr 19, 2005 8:55 pm

I've re-installed my ~x86 Gentoo over the weekend with the following CFLAGS:

Code: Select all

CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -funit-at-a-time"

I've yet to have problems with it.

LoSeR_5150 · Post by **LoSeR_5150** » Sun May 01, 2005 4:42 am

I have a pretty fast and fairly stable amd64 gentoo installed with the following CFLAGS:

CFLAGS="-march=athlon64 -O2 -fforce-addr -fmove-all-movables -fno-ident -fomit-frame-pointer -fpeel-loops
-fprefetch-loop-arrays -frename-registers -ftracer -funswitch-loops -funit-at-a-time -fweb -pipe"

CXXFLAGS="${CFLAGS}"

Any comments/suggestions on CFLAG/CXXFLAGS welcome...

also I have seen many people use the -fvisibility-inlines-hidden flag with CXXFLAGS however I have removed it
due to a handful of packages not compiling properly with it... i.e. glibmm, gtkmm, etc...

and to think i started with -march=athlon64 -02 -pipe... now my system is in its full riced glory

bgzee · Post by **bgzee** » Sun May 01, 2005 6:50 pm

LoSeR_5150 wrote:I have a pretty fast and fairly stable amd64 gentoo installed with the following CFLAGS:

CFLAGS="-march=athlon64 -O2 -fforce-addr -fmove-all-movables -fno-ident -fomit-frame-pointer -fpeel-loops
-fprefetch-loop-arrays -frename-registers -ftracer -funswitch-loops -funit-at-a-time -fweb -pipe"

CXXFLAGS="${CFLAGS}"

Any comments/suggestions on CFLAG/CXXFLAGS welcome...

also I have seen many people use the -fvisibility-inlines-hidden flag with CXXFLAGS however I have removed it
due to a handful of packages not compiling properly with it... i.e. glibmm, gtkmm, etc...

and to think i started with -march=athlon64 -02 -pipe... now my system is in its full riced glory

I plan on building gentoo from stage 1 on my amd64 but im gonna compile it for 32-bit. Can i use those same flags except change march to athlon instead of athlon64?

Grahammm · Post by **Grahammm** » Wed May 04, 2005 1:30 pm

I am about to take delivery of a system with a P4 which supports EM64T. Am I right in thinking that -march=prescott is the correct one if I use it in 32bit mode (x86) and -march=nocona should only be used for a 64bit build (amd64)? Or would -march=nocona be OK for a 32bit system?

Birtz · Post by **Birtz** » Wed May 04, 2005 8:21 pm

bgzee wrote:I plan on building gentoo from stage 1 on my amd64 but im gonna compile it for 32-bit. Can i use those same flags except change march to athlon instead of athlon64?

Grahammm wrote:I am about to take delivery of a system with a P4 which supports EM64T. Am I right in thinking that -march=prescott is the correct one if I use it in 32bit mode (x86) and -march=nocona should only be used for a 64bit build (amd64)? Or would -march=nocona be OK for a 32bit system?

Just make sure to start installing from x86-Gentoo-minimal/universal not amd64-* one. In this way, your CHOST would be set properly (e.g. i686-*) and in the endeffect you would have 32-bit system, no matter the march flags (so yes, you can use athlon64/nocona, just make sure the default compiler recognizes them, since stable x86 gcc is still 3.3.5).

Regards

Maedhros · Post by **Maedhros** » Wed May 04, 2005 8:53 pm

To be continued...

CFLAGS Central (Part 1)

my cflag line

doh

heh

;-

-march=prescott or nocona