Extreme CFLAGS problems...

[Enlight]

On my amd box, I never saw faster than -march=athlon-xp -O2 -fomit-frame-pointers (gcc 3.3.5 and 3.4.3) most of other stuffs gave me an extra slow-down when they didn't bork stuffs (only taking usr & sys in account.).

I'm currently using taviso's LDFLAGS but they borked emacs, so when it comes to emerge it, I remove 'em.

[Bob P]

So, kimchi...or anybody...please answer my question coz i'm kind of blur of this cflags rite now....

when in doubt, keep your cflags simple.

[whitesouls]

yeah..wat our saying is true oso...but i wanna learn and some other ppl will learn by reading our posts...tht's all...

[FastTurtle]

Here's my thinking on the whole issue of cflags:

1) Remove parsing of cflags/ldflags from make.conf but do keep cpu tuning something like this:

Choose your specific CPU if you want to maximize tuning. Otherwise stick with the Same Setting as your chost listing.

Recognized CPU's include Pentium, K6, K6-2(3), P3, P4, Athlon, Athlon-tbird, Athlon-Xp, Athlon64

and leave it at that.

2) Stick with stable Cflags in the ebuilds. Go for stability and if someone needs maximum performance they can still edit the ebuild themselves and realize they wont get alot of support from the devs.

3) Consolidate package.keywords package.use into make.conf for better optimiztions and strip from make.defaults any flag not required by the base build. This means No X unless it disables the feature such as -X -gnome.

I think this will retain the freedom of choice we all desire while reducing bug reports from insane cflags and ldflag options.

Final Option
Quit filtering cflags and allow darwin to take action. Anyone who's foolish enough to play with a loaded gun should just remove themselves from the gene pool and be done with it, thus saving us the time&effort of idiot proofing things for them while improving the Inteligence of the Species. Thank you for your consideratation and immediate implementation.

[IvanYosifov]

Quit filtering cflags and allow darwin to take action. Anyone who's foolish enough to play with a loaded gun should just remove themselves from the gene pool and be done with it, thus saving us the time&effort of idiot proofing things for them while improving the Inteligence of the Species. Thank you for your consideratation and immediate implementation.

Countrary to what you obviously believe, many CFLAGS problems are caused by lack of knowledge, not desire to push limits at all costs. Put simply: some people don't know that the thing they play with is a gun, and that it is loaded.

You seem to be interested in improving the situation. If so, once you see insane CFLAGS, post a 3-line reasonable explanation what exactly can go wrong. This will help a hell of a lot more than a 3-line "DIE FOOLISH IDIOT DIE" message !

Like it or not, the world in general and the Gentoo userbase in concrete is not composed of all-knowing semi-gods, and Gentoo is not an only-for-the-elite distro.

Darwin works all the time. If your suggestion is implemented ( filtering stopped ), Gentoo will die rather quickly. It simply wont work for too many people. Besides, there is not a single CFLAG that will work on all ebuilds.

Anger and frustration are bad, counter-productive. Go for a walk. Play some sport. Get some energy out

This is my thinking on the whole issue of CFLAGS.

[Gotterdammerung]

What about these CFLAGS:

Code: Select all

CFLAGS="-O2 \
        -mtune=athlon-xp \
        -pipe \
        -fomit-frame-pointer \
        -ftracer \
        -momit-leaf-frame-pointer \
        -fno-ident \
        -finline-functions \
        -fforce-addr \
        -fprefetch-loop-arrays  \
        -falign-functions=64 \
        -ffast-math"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

[96140]

What about these CFLAGS:

Code: Select all

CFLAGS="-O2 \
        -mtune=athlon-xp \
        -pipe \
        -fomit-frame-pointer \
        -ftracer \
        -momit-leaf-frame-pointer \
        -fno-ident \
        -finline-functions \
        -fforce-addr \
        -fprefetch-loop-arrays  \
        -falign-functions=64 \
        -ffast-math"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

-fprefetch-loop-arrays is bad for your health. and remove -falign-functions=64 immediately. And take out -ffast-math; that's a pretty well-known dangerous "optimization". -fno-ident is useless. And it's counterproductive to enable both -fomit-frame-pointer and -momit-leaf-frame-pointer. There's a thread floating around that compares the two and examines their effects when used. Pick one or the other, not both.

Change -mtune= to -march=; that's the best way to generate processor-specific code.

[IvanYosifov]

And it's counterproductive to enable both -fomit-frame-pointer and -momit-leaf-frame-pointer. There's a thread floating around that compares the two and examines their effects when used. Pick one or the other, not both.

Uh ? -fomit-frame-pointer implies -momit-leaf-frame-pointer. Using both is exactly the same as using only -fomit-frame-pointer, except when an ebuild filters one but not the other, however I don't know if such ebuilds exist and if they break. What thread are you refering to ?

Change -mtune= to -march=; that's the best way to generate processor-specific code.

I would suggest adding both -march and -mtune. ( I know the sense of this is debatable, just my 2c ).

[Enlight]

...

I guess he meant that as is trying to something that has already been done by gcc, so compile time waste only, cause IIRC -fomit-frame-pointer is member of ALLOWED_FLAGS.

[6D7474]

And it's counterproductive to enable both -fomit-frame-pointer and -momit-leaf-frame-pointer. There's a thread floating around that compares the two and examines their effects when used. Pick one or the other, not both.

Uh ? -fomit-frame-pointer implies -momit-leaf-frame-pointer. Using both is exactly the same as using only -fomit-frame-pointer, except when an ebuild filters one but not the other, however I don't know if such ebuilds exist and if they break. What thread are you refering to ?

Change -mtune= to -march=; that's the best way to generate processor-specific code.

I would suggest adding both -march and -mtune. ( I know the sense of this is debatable, just my 2c ).

-momit-leaf-frame-pointer overrides -fomit-frame-pointer...
take a look at http://forums.gentoo.org/viewtopic-t-33 ... rt-75.html

[96140]

-momit-leaf-frame-pointer overrides -fomit-frame-pointer...
take a look at http://forums.gentoo.org/viewtopic-t-33 ... rt-75.html

Thanks. This is the thread I was referring to. There's a couple of others, as well, but I haven't been able to find them again.

[pv]

I have a box with Athlon XP 2500+ (1833) (Barton). Now I use GCC 3.3.5-20050120 (x86) but I'm going to upgrade my system to use GCC-3.4.4 (~x86).
My CFLAGS are

Code: Select all

CFLAGS="-march=athlon-xp -O3 -momit-leaf-frame-pointer -fomit-frame-pointer \
-fno-align-jumps -fno-align-labels -fno-align-loops -fno-align-functions \
-mmmx -m3dnow -msse -ffast-math -mfpmath=sse -s -pipe"
LDFLAGS="-s"
CXXFLAGS="$CXXFLAGS"

I'd like to describe them first.

Code: Select all

-march=athlon-xp -O3 -fomit-frame-pointer -pipe

are recommended everywhere.

Code: Select all

-momit-leaf-frame-pointer

maybe helps me if emerge remove -fomit-frame-pointer and forget about the given flag. Am I right?

Code: Select all

-fno-align-jumps -fno-align-labels -fno-align-loops -fno-align-functions

are here because GCC aligns loops and labels by inserting a special processor instruction (nop) which do nothing but requires one processor cycle to execute it and a byte to store it in a program (to align). Moreover, aligning doesn't take place everytime it's needed but just if it can be made by inserting no more than 7 nop's. The default align is on 16-byte boundary so about a HALF OF ALL loops wouldn't be aligned at all! So, with these options I decrease a program size and (possibly) consequently the loading time.

Code: Select all

-mmmx -m3dnow -msse

allow programs to use machine-specific instruction sets mentioned. If a program doesn't know about ones it doesn't use them. Why not to add them?

Code: Select all

-s (CFLAGS and LDFLAGS)

removes debug (and what?) symbols from programs compiled. I know Gentoo strips result binaries with the 'strip' command but using the option I reach better results (this has been checked).
Can somebody advise me something else (-mpreferred-stack-boundary=8, for example) or just comment the thoughts above or the CFLAGS shown?
Should I do an upgrade to GCC-3.4.4? What GCC is faster and what gcc generates smaller binaries?

[Enlight]

-momit-leaf-frame-pointer overrides -fomit-frame-pointer...
take a look at http://forums.gentoo.org/viewtopic-t-33 ... rt-75.html

Thanks. This is the thread I was referring to. There's a couple of others, as well, but I haven't been able to find them again.

Uh? that's so weird to have -momit disablin -fomit , it should be the contrary I'm glad I only used -fomit-frame-pointer

[Gergan Penkov]

Well just my 2c, if someone depends on a broken app like acovea to set his/her cflags, it is his/her right to do so.
I've learned my lesson - even the fomit-frame-pointer could lead to visible slowdowns on athlonxp.
now i use only

CFLAGS="-march=athlon-xp -O2 -pipe"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

and i could bet that my system is faster and far more stable than most of what you have there with these cflags.
what about for example openoffice-2 draw starting in 5 seconds on athlonXP-2000+ ?

[Enlight]

Well just my 2c, if someone depends on a broken app like acovea to set his/her cflags, it is his/her right to do so.
I've learned my lesson - even the fomit-frame-pointer could lead to visible slowdowns on athlonxp.
now i use only

CFLAGS="-march=athlon-xp -O2 -pipe"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

and i could bet that my system is faster and far more stable than most of what you have there with these cflags.
what about for example openoffice-2 draw starting in 5 seconds on athlonXP-2000+ ?

How could making %ebp available for other things and replacing move %esp %ebp (and the opposite) by add or sub absolute values to %esp lead to slowdown?

And concerning LDFLAGS, I don't have many clues but I used to thing that --as-needed was breaking stuffs and should be used with great caution. Plus I don't thing "my" --sort-common an -fomit-frame-pointer (wich are the only extras I've got compared to you, could get me into particular troubles.

[Gergan Penkov]

This is my personal observation and probably depends on a compiler version, but I have had visible slowdowns on athlonxp, it could be that the implementation displaces the registers in some way. I have read only positive comments for pentium4, but on athlonxp ...
Yes, I know that --as-needed breaks things, but it is the way to go if you want speedup for the startup times, it is simply so that these flags or more of them will help on computational intensive tasks, so it is probably a good idea to have them in ffmpeg or mplayer but not on all the things you compile:)
and as-needed will reduce memory usage, which in term will bring faster desktop, there is a thread about it and it will break some 20 apps the others are just ok.

[Enlight]

Do you have any bench about the fomit-frame-pointer? I've got an athlon-xp and on the few apps I tested it, I saw major speed-up. I woul also be interested in seeing the list of the apps broken by --as-needed, a link or something?

[Gergan Penkov]

Now you could read little about how this began for me http://forums.gentoo.org/viewtopic-t-38 ... ight-.html, but there are no answers to this thread for now. The as-needed thread could be found here (with most of the broken packages and hints for per app {c|ld}flags) http://forums.gentoo.org/viewtopic-t-31 ... ight-.html
on the fomit-frame pointer - this was probably a year ago (in the time, when this acovea madness was really popular), so probably it was because the compiler, but I've had recompiled my whole system with it and it was sluggish - so I don't have any benchmarks or so and I don't have the time to test it one more time ::)) and I also don't have the reason to do it:)

[codergeek42]

Code: Select all

-march=athlon-xp -O3 -fomit-frame-pointer -pipe

are recommended everywhere.

"-O3" will break things. You really should be using "-O2" instead.

Code: Select all

-mmmx -m3dnow -msse

allow programs to use machine-specific instruction sets mentioned. If a program doesn't know about ones it doesn't use them. Why not to add them?

These are implied by "-march=athlon-xp," so you probably do not need them.

Code: Select all

-s (CFLAGS and LDFLAGS)

removes debug (and what?) symbols from programs compiled. I know Gentoo strips result binaries with the 'strip' command but using the option I reach better results (this has been checked).

Erm. You really don't want to strip everything. Lots of shared libraries (essentially almost everything in /lib and /usr/lib, think glibc, OpenSSL, etc.) won't work with nonexistant symbol tables!

[pv]

Lots of shared libraries (essentially almost everything in /lib and /usr/lib, think glibc, OpenSSL, etc.) won't work with nonexistant symbol tables!

Are you sure? I'm sitting at my box and writing this post and everithing seems ok. I haven't notice any problems for the last 3 or 4 months (4 months ago I started using Gentoo). Maybe ebuilds that won't work with these flags strip them.

[codergeek42]

Lots of shared libraries (essentially almost everything in /lib and /usr/lib, think glibc, OpenSSL, etc.) won't work with nonexistant symbol tables!

Are you sure? I'm sitting at my box and writing this post and everithing seems ok. I haven't notice any problems for the last 3 or 4 months (4 months ago I started using Gentoo). Maybe ebuilds that won't work with these flags strip them.

Good point then. I concede.