| View previous topic :: View next topic |
| Author |
Message |
Bobrepuss
n00b
Joined: 27 Feb 2005
Posts: 33
|
 Posted: Tue Apr 05, 2005 12:28 pm Post subject: my cflag line |
 |
|
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) |
|
| Back to top |
|
 |
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Tue Apr 05, 2005 12:34 pm Post subject: |
|
|
Yes. Especially if you change your make.conf C(XX)FLAGS to read: | Code: | 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: | 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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
Bobrepuss
n00b
Joined: 27 Feb 2005
Posts: 33
|
| Posted: Tue Apr 05, 2005 12:41 pm Post subject: doh |
|
|
Doh,
How badly is that impacting performance? I dont fancy starting out again :-/
But ill make the cflag changes, thanks for the advice  |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Tue Apr 05, 2005 12:50 pm Post subject: |
|
|
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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
Bobrepuss
n00b
Joined: 27 Feb 2005
Posts: 33
|
| Posted: Tue Apr 05, 2005 1:06 pm Post subject: heh |
|
|
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? |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Tue Apr 05, 2005 2:08 pm Post subject: |
|
|
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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
Bobrepuss
n00b
Joined: 27 Feb 2005
Posts: 33
|
| Posted: Tue Apr 05, 2005 2:26 pm Post subject: ;- |
|
|
just incase others try that link there is a dash http://www.gentoo-stats.org/
thanks
*Finished recompiling once, going to go again overnight |
|
| Back to top |
|
|
ingvildr
n00b
Joined: 18 Mar 2005
Posts: 45
|
| Posted: Wed Apr 13, 2005 5:48 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Wed Apr 13, 2005 7:00 pm Post subject: |
|
|
| 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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
ingvildr
n00b
Joined: 18 Mar 2005
Posts: 45
|
| Posted: Wed Apr 13, 2005 7:14 pm Post subject: |
|
|
this from gentoo-wiki.com
| Code: | -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. |
|
|
| Back to top |
|
|
stonent
Veteran
Joined: 07 Aug 2003
Posts: 1139
Location: Texas
|
| Posted: Wed Apr 13, 2005 7:16 pm Post subject: |
|
|
I always thought fomit-frame-pointer made things smaller by removing some debug information and this an overall optimization of size and speed.
_________________
Inspiron 4100 & Sun UltraAXe
Portage on Solaris|Dell Laptop Hacks
The way you feel about organized religion is the same way I feel about organized socialism. |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Wed Apr 13, 2005 7:26 pm Post subject: |
|
|
| ingvildr wrote: | this from gentoo-wiki.com
| Code: | -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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
elyre_elan
n00b
Joined: 31 May 2003
Posts: 51
Location: Colorado, USA
|
| Posted: Tue Apr 19, 2005 7:09 pm Post subject: |
|
|
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?
_________________
SCO has performed an illegal operation error and will be shut down. |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Tue Apr 19, 2005 8:52 pm Post subject: |
|
|
| 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.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Last edited by moocha on Tue Apr 19, 2005 8:55 pm; edited 1 time in total |
|
| Back to top |
|
|
codergeek42
Bodhisattva
Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)
|
| Posted: Tue Apr 19, 2005 8:55 pm Post subject: |
|
|
I've re-installed my ~x86 Gentoo over the weekend with the following CFLAGS: | Code: | | CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe -funit-at-a-time" |
I've yet to have problems with it. 
_________________
~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF |
|
| Back to top |
|
|
LoSeR_5150
Guru
Joined: 20 Mar 2005
Posts: 455
Location: San Francisco, CA
|
| Posted: Sun May 01, 2005 4:42 am Post subject: |
|
|
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  |
|
| Back to top |
|
|
bgzee
Tux's lil' helper
Joined: 11 Aug 2003
Posts: 116
|
| Posted: Sun May 01, 2005 6:50 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
Grahammm
Tux's lil' helper
Joined: 01 Sep 2004
Posts: 84
Location: Berkshire UK
|
| Posted: Wed May 04, 2005 1:30 pm Post subject: -march=prescott or nocona |
|
|
| 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? |
|
| Back to top |
|
|
Birtz
Apprentice
Joined: 09 Feb 2005
Posts: 272
Location: Osijek / Croatia
|
| Posted: Wed May 04, 2005 8:21 pm Post subject: |
|
|
| 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
_________________
It is not enough to have a good mind. The main thing is to use it well.
-- Rene Descartes
Don't have a childhood hero? How about Rob Hubbard http://www.freenetpages.co.uk/hp/tcworh/profile.htm |
|
| Back to top |
|
|
Maedhros
Bodhisattva
Joined: 14 Apr 2004
Posts: 5511
Location: Durham, UK
|
| Posted: Wed May 04, 2005 8:53 pm Post subject: |
|
|
To be continued...
_________________
No-one's more important than the earthworm. |
|
| Back to top |
|
|
|
Portage & Programming
