[gcc 3.4] AMD's Recommended CFLAGS

Message

nxsty · Post by **nxsty** » Sat Oct 29, 2005 5:38 pm

tnt wrote:Are some of these flags dangerous or bad in any other way:
Code: Select all
CFLAGS="-march=athlon64 -O2 -pipe -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -msse3"

-funswitch-loops and -funroll-all-loops are bad and will slow your system down. Punt -fpeel-loops also since it turns on the new loop optimizer (-floop-optimize2) which currently generates slower code than the old one used by default. -funit-at-a-time is included in -O2 so it's not nessecary.

tnt · Post by **tnt** » Sat Oct 29, 2005 7:32 pm

Is "-funroll-loops" OK?

energyman76b · Post by **energyman76b** » Sun Oct 30, 2005 3:03 am

Hi,

it depends

it can make your apps slower, because it makes them bigger and that way more cache hungry.
The only way to know for sure is to bench

But it is not as bad as funroll-all-loops.

flipik · Post by **flipik** » Mon Oct 31, 2005 11:47 am

energyman76b wrote:
flipik wrote:I set CFLAGS to "-march=athlon64 -mtune=athlon64 -O3 -funroll-loops -fpeel-loops -ftracer -pipe" and did emerge -e world..
Everything seem to work just fine.
yeah, but you do not need mtune, when you are using march.
Please read man gcc about mtune and march and why setting both is superflous and may give you unwanted results.

thanks for info.. I will check it..

nxsty · Post by **nxsty** » Mon Oct 31, 2005 12:45 pm

Loop unrolling can speed up some CPU intensive apps but usually it just creates unnessecary bloat. Don't put it in your CFLAGS for everything, it will only hurt performance.

energyman76b · Post by **energyman76b** » Mon Oct 31, 2005 1:02 pm

tnt wrote:
Code: Select all
[tnt@master ~]$ ./test.bin
cpuid(0) returns 1 (AuthenticAMD)
cpuid(1) returns 00020fc2 00000800 00000001 078bfbff
Result is 496498219533200
[tnt@master ~]$
Seems like it has SSE3. Thank you for this test - very useful !

yupp, everything is fine

but don't thank me, thank the guy who wrote it (and I forgot, where I copied it. Damn)

enderandrew · Post by **enderandrew** » Fri Nov 04, 2005 11:26 am

I'm probably just going to go with:

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -fpeel-loops -ftracer -pipe"

I know that several people here seem anti-ffast-math, however others insist they've had no problems using it for years and that it has substantial performance increases. If the packages it might break exclude it automatically, then there really isn't much of a risk, while it does in fact offer benefits.

My question is what about the following flags? These are all recommended in the AMD PDF file and I haven't seen anyone talk about these.

-fmove-all-movables -freduce-all-givs -mno-align-stringops -minline-all-stringops -mno-push-args

SoTired · Post by **SoTired** » Fri Nov 04, 2005 4:36 pm

enderandrew wrote:I'm probably just going to go with:

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -fpeel-loops -ftracer -pipe"

I would at least urge you to reconsider -funroll-loops and -fpeel-loops. You will speed up some programs, yes; but, you'll probably slow down an equal number.

enderandrew wrote:I know that several people here seem anti-ffast-math, however others insist they've had no problems using it for years and that it has substantial performance increases. If the packages it might break exclude it automatically, then there really isn't much of a risk, while it does in fact offer benefits.

The point with -ffast-math is that most packages that will derive any (substantial) benefit already have it enabled, and that it will occasionally break a package.

enderandrew wrote:My question is what about the following flags? These are all recommended in the AMD PDF file and I haven't seen anyone talk about these.

-fmove-all-movables -freduce-all-givs -mno-align-stringops -minline-all-stringops -mno-push-args

You may want to take a look at http://gcc.gnu.org/onlinedocs/gcc-3.4.4 ... tions.html.

-fmove-all-movables: Moves loop invariant computations outside of the loop. This is almost always a good thing, and I've never had this flag break anything. On the other hand, I've never had it offer a significant speed up to a program either.

-freduce-all-givs: Strength reduces loop variables. Strength reduction replaces an expensive operation on a variable with less expensive operations that accomplish the same transformation. Also a good thing. However, I have had this flag break the occasional program.

With the above two flags it's not so much what they're attempting to accomplish compared to how effective they actually are at it. With GCC 3.4.3 they rarely tend to enable any significant optimizations. This is probably because -floop-optimize and -fstrength-reduce (both enabled already at -O2) already deal with the cases that can yield any improvement.

-mno-align-stringops: YMMV with this flag, but I've never had any problems and have seen an insignificant improvement in string-heavy routines. (Has anyone seen many programs that really benefit from alignment on x86_64?)

-minline-all-stringops: The GCC manual's actually pretty clear on this one, "increase code size, but may improve performance of code that depends on fast memcpy, strlen and memset for short lengths." In other words it should definitely only be turned on, on a compile to compile basis, not for every program.

-mno-push-args: This will sometimes get you better out-of-order execution compared to using push and pop, never had any luck with it helping anything, though.

I'm surprised AMD didn't mention -maccumulate-outgoing-args, since for programs with a lot of recursion, or just many functions it almost always will speed things up. Though it will always bloat your binaries in the process.

energyman76b · Post by **energyman76b** » Sat Nov 05, 2005 2:58 am

enderandrew wrote:I'm probably just going to go with:

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -fpeel-loops -ftracer -pipe"

I know that several people here seem anti-ffast-math, however others insist they've had no problems using it for years and that it has substantial performance increases. If the packages it might break exclude it automatically, then there really isn't much of a risk, while it does in fact offer benefits.

that is plain wrong!

Some poor dev has to add a check for ffast math into the ebuild after some stupid guys, who insist on using it, despite being told by almost everybody, that it is just wrong, complaint all night long.

Nothing becomes excluded 'automatically'

And please - every app, that can safely use ffast-math is already doing so. So there is not one good reason to use it. But a lot against it.
One more would be, that all your bugs are worthless. Nobody can say for sure if a certain bug comes from the app, broken hardware, or some random ffast-math error.

nxsty · Post by **nxsty** » Sat Nov 05, 2005 1:20 pm

enderandrew wrote:I'm probably just going to go with:

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -fpeel-loops -ftracer -pipe"

I know that several people here seem anti-ffast-math, however others insist they've had no problems using it for years and that it has substantial performance increases. If the packages it might break exclude it automatically, then there really isn't much of a risk, while it does in fact offer benefits.

Well, 99% of the packages in portage builds and runs with -ffast-math in CFLAGS. But that's no guarantee that they'll work flawlessly. Mozilla for example has no problems building and running with -ffast-math it seems but then it crashes when the javascript console is used. A system compiled with -ffast-math will be unreliable and there is no way you can know that all your apps will behave as expected. And besides amd64 gccs defaults to SSE fpmath which don't go very well with -ffast-math so the speed gains are minimal.

enderandrew · Post by **enderandrew** » Sat Nov 05, 2005 3:53 pm

Here is the issue I'm seeing. The people who seem to be largely against many of these flags don't use them. The people who I see use them post they are quite happy. I've yet to see a post from someone say they did in fact run with those flags, and in the end regretted it.

Several people in this very thread say they compiled their entire system with flags like -ffast-math -funroll-loops, etc and had zero problems. Surely if Mozilla crashed on javascript, that problem would be quickly noted.

Someone earlier in the thread made a fairly good arguement about how and why -funroll-loops works specifically. It seemed the larger consensus was that -funroll-all-loops was bad, where as -funrull-loops really wasn't that bad.

At the moment, I keep waffling on whether or not I should build with flags like -funroll-loops. The only pure benchmarks I've seen are the ones in this thread with xmame. Most of the flags were inconsistent, sometimes yielding performance and sometimes not. However, when I added them up, it averaged to be a postive performance gain about about 2-3% most of the time.

I did read the GCC manual on optimizations, but I was looking for opinions of people who tried them. And to an extent I received them, so thank you.

Am I correct in understanding that you feel -fmove-all-movables -freduce-all-givs are both safe, but unlikely to produce big performance gains? I might try them since they seem safe. If they upside, great. What I'm really looking at is comparing risk versus potential reward. The potential isn't great, but they don't seem to have any real downside either. So why not give them a shot?

I might try the following:

CFLAGS="-O3 -march=athlon64 -ftracer -pipe -fmove-all-movables -freduce-all-givs"

Again, I've also heard not to build your whole system on O3, where as others have reported zero problems. My thinking is that I can always roll backwards on CFLAGS. If I try aggressive CFLAGS and I have problems, then I go with more conservative options and recompile. Honestly, I'm shocked there aren't more posters here eager to twink and experiment. Isn't that part of the fun?

If I'm ever really going to do it, then the best time is when I'm first getting into Gentoo and attempting to learn. If I have to reinstall, I'm not losing much.

nxsty · Post by **nxsty** » Sat Nov 05, 2005 4:31 pm

Several people in this very thread say they compiled their entire system with flags like -ffast-math -funroll-loops, etc and had zero problems. Surely if Mozilla crashed on javascript, that problem would be quickly noted.

The mozconfig eclass runs strip-flags to prevent that from happening becaue of ricers like you. But a lot of ebuilds doesn't run strip-flags. Compile perl with -ffast-math and run the testsuit and see for yourself.

Again, I've also heard not to build your whole system on O3, where as others have reported zero problems. My thinking is that I can always roll backwards on CFLAGS. If I try aggressive CFLAGS and I have problems, then I go with more conservative options and recompile. Honestly, I'm shocked there aren't more posters here eager to twink and experiment. Isn't that part of the fun?

Because there is no purpose. You wont get any performance increase by messing with the CFLAGS. In fact it usually makes the system slower because of unnecessary bloat. -O3 and -funroll-loops are good example of flags that bloats for small gains in specific applications. Only -O2 enables a lot of optimizations and is the most optimal to use system wide. FreeBSD even compiles everything with -O1 and still has great performance.

And I have tried all these flags myself. I used to be a ricer when I was new to gentoo about 1,5-2 years ago. Check out this old bugreport by me:
http://bugs.gentoo.org/show_bug.cgi?id=44276
But I stoped doing that because it's pointless and bad for performance.

energyman76b · Post by **energyman76b** » Sat Nov 05, 2005 9:09 pm

enderandrew wrote:Here is the issue I'm seeing. The people who seem to be largely against many of these flags don't use them. The people who I see use them post they are quite happy. I've yet to see a post from someone say they did in fact run with those flags, and in the end regretted it.

People against stupid/mad/ricer cflags, are mostly ones, who have seen enough carnage so they try to prevent further one.
I am using gentoo since 1.0.
I had my 'stupid' phase too, around 1.2, 1.4rc. And I have seen so many problems back then, that I just want to preserve you to walk into the same traps.

The most 'ricer' flags, make your system slower than basic ones, unreliable, unpredictable and brittle. The 'happy ricer flags' users, are also among those, who like to forget, that they hit some severe problem two weeks ago, or had to reinstall last month.

I want to tell you something: all reinstalls I did were because of harddisk crashes or update from athlon-xp to amd64. That makes for installs (4). How many times had the members of the happy cflags crowed reinstalled their systems?

Oh, and there is no magic cflag, that makes your system 10% faster. There are some, that makes your system 10% slower, but do you really want that?

And why do you think, are some CFLAGS not part of O2 or O3? What is the difference between them? You should be able to answer that for yourself.

Birtz · Post by **Birtz** » Sat Nov 05, 2005 9:45 pm

energyman76b wrote:
tnt wrote:
Code: Select all
[tnt@master ~]$ ./test.bin
cpuid(0) returns 1 (AuthenticAMD)
cpuid(1) returns 00020fc2 00000800 00000001 078bfbff
Result is 496498219533200
[tnt@master ~]$
Seems like it has SSE3. Thank you for this test - very useful !
yupp, everything is fine

but don't thank me, thank the guy who wrote it (and I forgot, where I copied it. Damn)

You are both quite welcome

http://forums.gentoo.org/viewtopic-t-32 ... ight-.html

Regards

Trevoke · Post by **Trevoke** » Thu Jan 12, 2006 8:40 pm

Horribly reviving this with ...

http://www.amd.com/us-en/assets/content_type/ white_papers_and_tech_docs/25112.PDF
Software Optimization Guide for the AMD64 Processors

I think that could be a good read

InsaneHamster · Post by **InsaneHamster** » Thu Jan 12, 2006 11:13 pm

Code: Select all

CFLAGS="-march=k8 -O2 -pipe -mmmx -msse -msse2 -msse3 -m3dnow -m64"

works fine for me ~amd64 2005.1 profile. (only problem compiling was libstdc++-V3 for ati drivers. it uses gcc 3.3 so i had to use athlon-xp 32bit flag)

and i guess libperl + perl during the install (i assume this is a stage1 problem not the flags)

InsaneHamster · Post by **InsaneHamster** » Thu Jan 12, 2006 11:15 pm

SoTired wrote:
enderandrew wrote:I'm probably just going to go with:

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-loops -fpeel-loops -ftracer -pipe"
I would at least urge you to reconsider -funroll-loops and -fpeel-loops. You will speed up some programs, yes; but, you'll probably slow down an equal number.

enderandrew wrote:I know that several people here seem anti-ffast-math, however others insist they've had no problems using it for years and that it has substantial performance increases. If the packages it might break exclude it automatically, then there really isn't much of a risk, while it does in fact offer benefits.
The point with -ffast-math is that most packages that will derive any (substantial) benefit already have it enabled, and that it will occasionally break a package.

enderandrew wrote:My question is what about the following flags? These are all recommended in the AMD PDF file and I haven't seen anyone talk about these.

-fmove-all-movables -freduce-all-givs -mno-align-stringops -minline-all-stringops -mno-push-args
You may want to take a look at http://gcc.gnu.org/onlinedocs/gcc-3.4.4 ... tions.html.

-fmove-all-movables: Moves loop invariant computations outside of the loop. This is almost always a good thing, and I've never had this flag break anything. On the other hand, I've never had it offer a significant speed up to a program either.

-freduce-all-givs: Strength reduces loop variables. Strength reduction replaces an expensive operation on a variable with less expensive operations that accomplish the same transformation. Also a good thing. However, I have had this flag break the occasional program.

With the above two flags it's not so much what they're attempting to accomplish compared to how effective they actually are at it. With GCC 3.4.3 they rarely tend to enable any significant optimizations. This is probably because -floop-optimize and -fstrength-reduce (both enabled already at -O2) already deal with the cases that can yield any improvement.

-mno-align-stringops: YMMV with this flag, but I've never had any problems and have seen an insignificant improvement in string-heavy routines. (Has anyone seen many programs that really benefit from alignment on x86_64?)

-minline-all-stringops: The GCC manual's actually pretty clear on this one, "increase code size, but may improve performance of code that depends on fast memcpy, strlen and memset for short lengths." In other words it should definitely only be turned on, on a compile to compile basis, not for every program.

-mno-push-args: This will sometimes get you better out-of-order execution compared to using push and pop, never had any luck with it helping anything, though.

I'm surprised AMD didn't mention -maccumulate-outgoing-args, since for programs with a lot of recursion, or just many functions it almost always will speed things up. Though it will always bloat your binaries in the process.

just a quick side note i read that the "k8" march cflag will include all the specific optimizations like -funroll-loop and such.

robak · Post by **robak** » Thu Jan 12, 2006 11:54 pm

i just have two little questions:

1. where are differences between the USE-FLAGS "mmx mmxext sse sse2 3dnow 3dnowext" and the CFLAGS "-mmmx -msse -msse2 -m3dnow"
and what is the CFLAG "m64" for?
2. why are the USE-FLAGS "mmx mmxext sse sse2 3dnow 3dnowext" masked by /use/portage/profiles/default-linux/use.mask ? does the USE-FLAG "amd64" include all the other optimizations like mmx and sse ?

nxsty · Post by **nxsty** » Fri Jan 13, 2006 3:07 pm

InsaneHamster wrote:just a quick side note i read that the "k8" march cflag will include all the specific optimizations like -funroll-loop and such.

No it wont. -march=k8 only includes cpu/arch optimizations. No optimization flag that I'm aware of includes -funroll-loops except if you're compiling with profiling enabled.

nxsty · Post by **nxsty** » Fri Jan 13, 2006 3:14 pm

robak wrote:i just have two little questions:

1. where are differences between the USE-FLAGS "mmx mmxext sse sse2 3dnow 3dnowext" and the CFLAGS "-mmmx -msse -msse2 -m3dnow"
and what is the CFLAG "m64" for?
2. why are the USE-FLAGS "mmx mmxext sse sse2 3dnow 3dnowext" masked by /use/portage/profiles/default-linux/use.mask ? does the USE-FLAG "amd64" include all the other optimizations like mmx and sse ?

The CFLAGS -mmx, -msse and friends enables compiler buitlins for mmx and sse etc. You don't need to specify those if you have a correct -march= switch except if you have a venice core amd64 where you also can use -msse3.

The mmx, sse and friends USE-flags usually enables assembly optimizations if a package supports it. You don't need to specify these on amd64 since they are on by default and that's the reason they are masked.

-m64 enables building of 64 bit code. It's also on by default on amd64 so don't set it as it might break stuff that needs some parts to be compiled 32 bit.

InsaneHamster · Post by **InsaneHamster** » Fri Jan 13, 2006 11:35 pm

nxsty wrote:
InsaneHamster wrote:just a quick side note i read that the "k8" march cflag will include all the specific optimizations like -funroll-loop and such.
No it wont. -march=k8 only includes cpu/arch optimizations. No optimization flag that I'm aware of includes -funroll-loops except if you're compiling with profiling enabled.

hmm well i cant remember where altough i read it altought it was legit and it did say that march=k8 would include specific optimazations like funroll fpic and all that

is there a way i can test it to see if it acctually does ?

i do notice that -fpic is automatically thrown in when compiling i dont know if the otheres are .

nxsty · Post by **nxsty** » Sat Jan 14, 2006 9:16 am

InsaneHamster wrote:hmm well i cant remember where altough i read it altought it was legit and it did say that march=k8 would include specific optimazations like funroll fpic and all that

is there a way i can test it to see if it acctually does ?

i do notice that -fpic is automatically thrown in when compiling i dont know if the otheres are .

Funroll fpic you say?

Anyway, try this:

touch dummy.c
gcc -v -Q -march=k8 dummy.c

Super Nade OCG · Post by **Super Nade OCG** » Sat Jan 14, 2006 5:06 pm

Wow man! This is my second Gentoo stage 1 install (in fact its my second install, period.

) and those flags (first post) worked perfectly without breaking anything. Zero seg faults and zero compilation errors. Compiled everything including kde and x11.

nxsty · Post by **nxsty** » Sat Jan 14, 2006 7:58 pm

Super Nade OCG wrote:Wow man! This is my second Gentoo stage 1 install (in fact its my second install, period. ) and those flags (first post) worked perfectly without breaking anything. Zero seg faults and zero compilation errors. Compiled everything including kde and x11.

This thread should be left to rot in the archives before more people do the same misstake.

sigmalll · Post by **sigmalll** » Sat Jan 14, 2006 8:32 pm

The problem is there is no definitive guide to the issue. On the one hand you have the ultra caucious saying -O2 and no further, in the next message you have -O3 -feverthing_under_the_sun saying everthing works perfectly. A couple of benchmarks here and there (usually done with totally different settings) that sort of back the O3'ers up, followed by an O2 pointing out that -feverything_under_the_sun breaks unrelated utility package Q (which nobody cares about anyway).

Everybody who reads the GCC docs on the subject comes up with a slightly different list of flags to use, and if they bother to post them here they get conflicting advice.

What we need is a list of applications to benchmark/test, a script to fire each one sequentially and save the results, and perhaps a DB online that shows whats faster, whats slower and what breaks.

Then users will be in a position to pick a useful set of CFLAGS for a specific CPU. Until then were going to find ourselves going round in circles in this thread (or another just like it) month after month after month.