Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Changing Cflags - bad idea?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Fri Jul 09, 2004 2:06 pm    Post subject: Changing Cflags - bad idea? Reply with quote

Hi,

my gentoo-box is running for about a year now and I compiled it with the following cflags:

Code:
CFLAGS="-march=athlon-xp -pipe -O2 -funroll-loops"


I'm now planning to change the CFLAGS to:

Code:
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops"


Will this break my gentoo or is it save? If not, should I rebuild all packages?

Thanks. :)
Back to top
View user's profile Send private message
SPW
Guru
Guru


Joined: 22 Jul 2003
Posts: 318
Location: Lëtzebuerg

PostPosted: Fri Jul 09, 2004 2:11 pm    Post subject: Reply with quote

The code you compiled with the "old" CFlags will still run. (You haven't changed your CPU).
I also changed my CFlags once and I didn't have any problems. I wouldn't recompile everything. As new packages will be available you will step by step recompile about all the packages that are installed on your system.
Back to top
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Fri Jul 09, 2004 2:34 pm    Post subject: Reply with quote

Thank you very much. :)
Back to top
View user's profile Send private message
SPW
Guru
Guru


Joined: 22 Jul 2003
Posts: 318
Location: Lëtzebuerg

PostPosted: Fri Jul 09, 2004 3:15 pm    Post subject: Reply with quote

You're welcome :D
Back to top
View user's profile Send private message
irf2003
Veteran
Veteran


Joined: 10 Sep 2003
Posts: 1078

PostPosted: Fri Jul 09, 2004 3:42 pm    Post subject: Reply with quote

how about
Code:

CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"

i would leave the "-funroll-loops" unless of course
http://funroll-loops.org/
hth
Back to top
View user's profile Send private message
spb
Retired Dev
Retired Dev


Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK

PostPosted: Fri Jul 09, 2004 3:58 pm    Post subject: Reply with quote

-funroll-loops isn't really that helpful most of the time. Stick with the standard -O? settings unless you've got hard evidence that one flag makes a huge difference. Most of the time, Compiler Developers Know Best. Personally, I'm running with
Code:
-march=athlon-xp -O3 -ftracer -fomit-frame-pointer -pipe

That's perfectly stable, and causes no problems. -ftracer does seem to make a difference, and afaik the only reason it's not included in -O3 is that it's fairly new.
Back to top
View user's profile Send private message
irf2003
Veteran
Veteran


Joined: 10 Sep 2003
Posts: 1078

PostPosted: Fri Jul 09, 2004 4:11 pm    Post subject: Reply with quote

thebell wrote:
-funroll-loops isn't really that helpful most of the time. Stick with the standard -O? settings unless you've got hard evidence that one flag makes a huge difference. Most of the time, Compiler Developers Know Best. Personally, I'm running with
Code:
-march=athlon-xp -O3 -ftracer -fomit-frame-pointer -pipe

That's perfectly stable, and causes no problems. -ftracer does seem to make a difference, and afaik the only reason it's not included in -O3 is that it's fairly new.

i doubt whether developers test their code with "-O3 -ftracer", i must admit though
that most of the time with the above compiler flags the code may compile
fine, however, in equal measure i doubt whether it will run in the manner in which
the developers envisaged. but, on the other hand, you may not care for that.
all these so called optimizations are just a myth, and even if they are not,
their contribution to performance are at best marginal...
hth
Back to top
View user's profile Send private message
spb
Retired Dev
Retired Dev


Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK

PostPosted: Fri Jul 09, 2004 4:30 pm    Post subject: Reply with quote

irf2003 wrote:
i doubt whether developers test their code with "-O3 -ftracer", i must admit though
that most of the time with the above compiler flags the code may compile
fine, however, in equal measure i doubt whether it will run in the manner in which
the developers envisaged. but, on the other hand, you may not care for that.
all these so called optimizations are just a myth, and even if they are not,
their contribution to performance are at best marginal...
hth
Yes, I'm aware of that point of view. ;) However, -ftracer is unlikely to break anything, and I'm guessing that most code gets tested decently at -O3. And if it doesn't work, the ebuild will filter it out, as -O3 is such a common and relatively sane flag.
Back to top
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Fri Jul 09, 2004 4:59 pm    Post subject: Reply with quote

irf2003 wrote:
how about
i would leave the "-funroll-loops" unless of course
http://funroll-loops.org/
hth


That webpage is the reason why I included funroll-loops. :D
Back to top
View user's profile Send private message
irf2003
Veteran
Veteran


Joined: 10 Sep 2003
Posts: 1078

PostPosted: Fri Jul 09, 2004 5:16 pm    Post subject: Reply with quote

thebell wrote:
irf2003 wrote:
i doubt whether developers test their code with "-O3 -ftracer", i must admit though
that most of the time with the above compiler flags the code may compile
fine, however, in equal measure i doubt whether it will run in the manner in which
the developers envisaged. but, on the other hand, you may not care for that.
all these so called optimizations are just a myth, and even if they are not,
their contribution to performance are at best marginal...
hth
Yes, I'm aware of that point of view. ;) However, -ftracer is unlikely to break anything, and I'm guessing that most code gets tested decently at -O3. And if it doesn't work, the ebuild will filter it out, as -O3 is such a common and relatively sane flag.

as far as i'm concerned -O3 is unsafe, period, and so is -ftracer, at least from
personal experience.
of course i'm a nobody, you can always convince the community.
was a programmer, at least 20 years ago, and blieve me, the last thing i used
to worry about when coding were the compiler flags. maybe, the programming
craft has changed since the last twenty years, but, even if it has, i guess
you cannot teach an old horse new tricks, therefore, ideally, let us leave compiler flags to ./configure and make, after all whoever coded the app
happens to have coded the configure and make scripts
if you know better, you are welcome to contribute to the original developers
and convince them that your compiler flags should be the defaults ones.
hth
any compiler flags
Back to top
View user's profile Send private message
spb
Retired Dev
Retired Dev


Joined: 02 Jan 2004
Posts: 2135
Location: Cambridge, UK

PostPosted: Fri Jul 09, 2004 5:20 pm    Post subject: Reply with quote

Yes, that's exactly the reason I'm not using -march=athlon-xp -mmmx -msse -mfpmath=sse -O3 -ftracer -ffast-math -funroll-all-loops -fnew-ra -freduce-all-givs (not to mention that it's redundant and probably slower). The flags I'm using work perfectly, and have caused exactly zero problems. If a package doesn't compile with -O3, then the ebuild filters it, since (by most gentoo users' standards) -O3 -ftracer is a relatively tame set of flags.
Back to top
View user's profile Send private message
irf2003
Veteran
Veteran


Joined: 10 Sep 2003
Posts: 1078

PostPosted: Fri Jul 09, 2004 5:21 pm    Post subject: Reply with quote

Tenobok wrote:
irf2003 wrote:
how about
i would leave the "-funroll-loops" unless of course
http://funroll-loops.org/
hth


That webpage is the reason why I included funroll-loops. :D

yeah let -f0xor-loop rulz!(is that who it's spelled?)
what can i say more?
man, grow up!
hth
Back to top
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Fri Jul 09, 2004 5:47 pm    Post subject: Reply with quote

irf2003 wrote:

yeah let -f0xor-loop rulz!(is that who it's spelled?)
what can i say more?
man, grow up!
hth


You are not a very humorous person, right?
Yeah, but I know - It's easier to judge people if you don't know them.

Yes, I have "funroll-loops" in my cflags for fun, so what?

If I'm on your shitlist because of that, then you are the one who should grow up.
Back to top
View user's profile Send private message
irf2003
Veteran
Veteran


Joined: 10 Sep 2003
Posts: 1078

PostPosted: Fri Jul 09, 2004 7:19 pm    Post subject: Reply with quote

Tenobok wrote:
irf2003 wrote:

yeah let -f0xor-loop rulz!(is that who it's spelled?)
what can i say more?
man, grow up!
hth


You are not a very humorous person, right?
Yeah, but I know - It's easier to judge people if you don't know them.

Yes, I have "funroll-loops" in my cflags for fun, so what?

If I'm on your shitlist because of that, then you are the one who should grow up.

hey, use any compiler flag you care to, and as far you are concerned
you are on my whitelist, you being a gentoo user, that is why i cannot
BS you, i tell you the truth as far as i understand it, you do not have to believe
me, and that is your prerogative.
the rest is up to you, in the best tradition of gentoo, do it your own way,
i am sorry if i had offended you or any other gentooer for that matter
hth
and happy gentooing
Back to top
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Sat Jul 10, 2004 3:12 am    Post subject: Reply with quote

irf2003 wrote:

hey, use any compiler flag you care to, and as far you are concerned
you are on my whitelist, you being a gentoo user, that is why i cannot
BS you, i tell you the truth as far as i understand it, you do not have to believe
me, and that is your prerogative.


But what should I believe you? You never stated anything about funroll-loops. You had a discussion about "-ftracer" and in that case, I think you are right. It's a new flag and might break something.

But what's the deal with funroll-loops? As far as I read your posts "funroll-loops" is only evil, because some website is making fun of it.

If there are any technical reasons why this flag shouldn't be used, please tell me, I'm always eager to lern.
What pissed me off was that you just started bashing me without telling me why this flag is so bad. My comment was meant to be funny.

I hope to get an answer.

Happy gentooing to you too, of course. :)
Back to top
View user's profile Send private message
oberyno
Guru
Guru


Joined: 15 Feb 2004
Posts: 467
Location: /bin/zsh

PostPosted: Sat Jul 10, 2004 4:51 am    Post subject: Reply with quote

Tenobok: from the gcc man page:
Code:
-funroll-loops
           Unroll loops whose number of iterations can be determined at com-
           pile time or upon entry to the loop.  -funroll-loops implies -fre-
           run-cse-after-loop.  It also turns on complete loop peeling (i.e.
           complete removal of loops with small constant number of itera-
           tions).  This option makes code larger, and may or may not make it
           run faster.

So basically, it tries to make code faster, but increases the size quite a bit. Some packages will benefit, while many others will slow down. Plus, it has a funny name.

On a side note, my computer performs better without -ftracer. I have a athlon-xp 1800+ palomino with 256kb cache if that helps. I was doing some basic benchmarking of lame the other day, and it performed better without the ftracer. Perhaps this flag isn't for everyone?
Back to top
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Sat Jul 10, 2004 10:57 am    Post subject: Reply with quote

oberyno wrote:
Tenobok: from the gcc man page:
Code:
-funroll-loops
           Unroll loops whose number of iterations can be determined at com-
           pile time or upon entry to the loop.  -funroll-loops implies -fre-
           run-cse-after-loop.  It also turns on complete loop peeling (i.e.
           complete removal of loops with small constant number of itera-
           tions).  This option makes code larger, and may or may not make it
           run faster.



Thanks, but that was the part I did already know (I read that manpage, too).
My question was more like, whether or whether not 'funroll-loops' does anything evil, like making some ebuild segfault oder stop ebuilds from compiling right.

Slightly bigger files is surely no problem in the time of 120GB-HDs. ;)
Back to top
View user's profile Send private message
oberyno
Guru
Guru


Joined: 15 Feb 2004
Posts: 467
Location: /bin/zsh

PostPosted: Sun Jul 11, 2004 12:12 am    Post subject: Reply with quote

I doubt funroll-loops would do anything evil like break something. Still though you should look more into it before you add it to your default cflags.

For examle, you could benchark lame without the particular cflag in question, then with the cflag and compare the results. Or use povray. Or anything else you are likely to use alot that lends itself to benchmarking. Also, remember that what is good for one processor is not necessarily good for another.

And about the larger code size, I think that comes more into play when its going through cache, but I may be wrong.

Edit: The last ebuild I used personally that broke with ftracer was wesnoth, and that was filtered out a while ago.
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Sun Jul 11, 2004 12:31 am    Post subject: Reply with quote

-funroll-loops and/or -funroll-all-loops almost certainly won't break anything, but they will cause slowdowns most of the time. They bloat the code size something awful, causing a lot of cache misses. Do not use them except when they're implied by the catch-all -O2/-O3 options (depending on the compiler version).
As far as I'm aware (and I am, having tried & tested all gcc versions since it was introduced) -ftracer doesn't break a thing and marginally improves runtime behavior (~2-3% speedup). The one notable exception is tetex. -ftracer breaks that one. Disable it temporarily when merging tetex.

Edit: Typo.
_________________
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
View user's profile Send private message
Tenobok
Apprentice
Apprentice


Joined: 09 Jul 2004
Posts: 199
Location: This planet

PostPosted: Sun Jul 11, 2004 1:14 am    Post subject: Reply with quote

Thanks for the answers - I never stop learning ;)
Back to top
View user's profile Send private message
tomthewombat
Apprentice
Apprentice


Joined: 29 Mar 2003
Posts: 244
Location: NY State

PostPosted: Sun Jul 11, 2004 2:40 am    Post subject: Reply with quote

A few things I have learned along the way:

Now-a-days, Portage will filter any of the more popular cflags if they are known to cause breakage.

One important thing to mention first is mcpu. Yes, it is implied by march. However, there is a chance Portage will filter out your march flag (because it causes breakage with the ebuild). You should definately include mcpu=athlon-xp because it will still perform safe code optimizations specific to your processor even if march is filtered out.

As mentioned above, you should leave the technology flags (mmx, sse, and 3dnow) to the compiler. It does well at deciding when to use these technologies.

Past that, there are many camps on the CFLAG issue. Some prefer size (so programs load faster) others prefer sheer runtime speed. Either way, nobody can argue that O2 is always safe.

fomit-frame-pointer removes the debug code from your programs. This makes your programs significantly smaller, but causes a minor decrease in runtime performance. Unless you have all day to wait for your programs to load, this is a safe option. (note: I believe momit-leaf-frame-pointer does something along the same lines, but is not nearly as significant.

ftracer seems to cause a significant runtime improvement, and a slight size impovement. It is 99% stable. I belive I heard it was slated to be considered for inclusion in O3.

That leave us with O2 and O3. O3 contains 3 more flags than O2: -frename-registers, -fweb, and -finline-functions.

-frename-registers and -fweb both tend to be positive for the most part. There is almost no reason not to include these ontop of your O2.

-finline-functions compiles small functions inline with the code. This way, the program does have to 'call out' to them. Instead it can run straight through the code. Because 'calling out' to functions isn't as easy as running straight code, this causes a runtime speed increase, but can severely enlarge some applications. The speed camp says yay! and the size camp says nay!

funroll-loops mostly slows things down. ffastmath is generally good for runtime and nuetral on size, but causes breakage in several major ebuilds.

My experience is that CFLAGS don't really matter that much. You will notice an improvement from no optimization to full optimization, but its extremely hard to tell the grey areas without specific benchmarks tailored to the application you are compiling.

The new schedulers and improvements in the 2.6 kernel and many of the patchsets being developed (with hopes of making it into the kernel) provide far more noticable 'performance increases.' Like CFlags, many of these improvements come at a cost. Although usually the cost is low and well worth the trade.

On a personal note: my cflags

-O2 -march=athlon-xp -mcpu=athlon-xp -ftracer -fweb -frename-registers -fomit-frame-pointer -pipe

I am testing out the 'size' camp right now. The differences are minor. It mostly comes down to how you use your computer.

I hope this helps you and many others.
_________________
http://www.wombatorium.net
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Sun Jul 11, 2004 2:55 am    Post subject: Reply with quote

Nod, I fully agree with your post. I'm not siding with either camp - or rather, I consider both camps to not having fully considered what "size" means. CPU (L1- and L2-) cache misses will hurt performace far, far worse than the latest in loop unrolling and function inlining can offset (unless you're the happy owner of a CPU with megabytes of L2 cache, that is ;-) )
However, the "program load" issue seems to be the cause of a lot of confusion. Code size (i.e. executable binary size) has virtually no influence on application load times. High application load times arise is the vast majority of cases due to cache starvation (-O3 on small-cache CPUs) or slow disk access. Using nothing higher than -O2 -ftracer on small-cache CPUs, ensuring that UltraDMA is enabled on ATA disk access, using SCSI disks, and using the right IO scheduler will solve that issue.
_________________
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
View user's profile Send private message
tomthewombat
Apprentice
Apprentice


Joined: 29 Mar 2003
Posts: 244
Location: NY State

PostPosted: Sun Jul 11, 2004 3:35 am    Post subject: Reply with quote

woops. yeah you're right... loading into cache, or however you properly term it.

I would say that things are a little better without inlining, but its extremely hard to tell and mostly sensative to person preference on most desktop hardware.

I hear rumors that the large caches may infact tend to slow things down unless you make heavy use of such flags. They aren't totally reliable sources though.
_________________
http://www.wombatorium.net
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Sun Jul 11, 2004 3:45 am    Post subject: Reply with quote

tomthewombat wrote:
I hear rumors that the large caches may infact tend to slow things down unless you make heavy use of such flags. They aren't totally reliable sources though.


True, but indirectly. It's a self-selected issue, because processors with huge caches (i.e. P4 Xeons) also have a very long execution pipeline. For them the bottleneck is actually on the cache fetch side, not on the execution side. The problem is keeping the processor core(s) busy enough - and unless inling a lot the pipeline(s) will stall waiting for the cache subsystem to feed them.

Edit: s/memory\ fetch/cache\ fetch/
_________________
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
View user's profile Send private message
pkd
n00b
n00b


Joined: 17 Mar 2004
Posts: 53

PostPosted: Sun Jul 11, 2004 6:53 am    Post subject: Reply with quote

Unless you have a good reason not to, you should probably just be using the standard stuff.
Code:
-O2 -march=whatever -fomit-frame-pointer -pipe


If you're running a high-load server, play around with CFLAGS all you want to get the most out of your hardware. If you want to make your email client start 0.1% faster, well then you're just being silly. There are more important things in life ;)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum