Making full use of cpu registers in CFLAGS

[Gnufsh]

I'm using simply:
CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
right now on my athlon-xp with gcc-3.4.2-r2.

[Nate_S]

For those of you with athlon-xp's: I've heard that -mfpmath=sse can actually slow things down. The reason for this is because AMD's sse implementation is kind of weak compared to intel's (it's there so that it can run precompiled sse code,) however, it has one monster of a 387 coprocesser. (I have not tried both of them at once)

-Nate

[ktm]

The only way to find out what cflags is the best for your cpu, is to do some kind of benchmarking. In the big cfalg threat, CFlags central https://forums.gentoo.org/viewtopic.php?t=5717&start=775&postdays=0&postorder=asc, someone called blackcat4 made a script to benchmark different cflag http://blackcat.ca/dist/bench_gcc

I used the script to benchmark a Pentium II 366Mhz (old IBM Thinkpad 570) with lame (the mp3 encoder). The script compiles lame using one kind of cflags, then run lame three times converting a wav-file to mp3. After this, it does the same again, just using different cflags.

I tried about 15 different cflags, and to my surprise almost all of them just made my run time slower, including -pipe and -funroll-loops. I found that the fastest cflags for my old Pentium 2 is:

[chickaroo]

wow i've read every post here and now i'm even more confused as to what i should use lol. i've read the gcc manual about 5 times... and also other sources. my latest CFLAGS have been:

[Warped_Dragon]

I clicked this thread looking for some ways to further optimize my CFLAGS and/or LDFLAGS. Now I'm just confused :/ Is there a list anywhere, listing CPU types and suggested flags to be used with them?

For instance, mine are:

[chickaroo]

well, there are different types of durons... some based on the athlon and some based on the athlon-xp. that's a 1GHz so i would be guessing it's an athlon. so i'd suggest -march=athlon
_________________
Registered Linux user #364515 (Jun, 2004)

[Warped_Dragon]

Ah. I didn't even know what it was based on :/ Thanks

[Nate_S]

chickaroo:

AFAIK there is seperate execution units for 387 code and sse code. Also AFAIK, the athlon does have poor sse, compared to a pentium of the same class. (and it's 387 is better than the same pentium's) However, which one will actually be faster really, really depends on the code in question. For a P4, it's safe to always set it to sse, where as for an athlon, some code may do better with it set to 387 or vice versa.

My understanding (and I could be way off) is that using both 387 and sse optimizes the code for both, such that it can execute them both in parallel, effectively doubleing your floating point processing power. however, this often causes very wierd results, and some code will crash and burn with this.

I'd advise against dropping -funroll-loops, as your startup times may get faster, as an app is loaded into memory, but running the app will most likely get slower, as once in memory you want free registers and quick execution.

Man I wish I could find the thread I was given this advice in, as the guy there states it far more elequently than me, but search hates me.

-Nate

[LockeAverame]

some people never learn:
first: there are no cflags which are perfect for every program because the compiler mostly uses heuristics for optimization decisions and gcc has not a very good register allocator.

second: your duron is based on the morgan core (you can see it on the cpu frequency and the sse support), so use -march=athlon-xp.

third: mostly the binaries get about a maximum of 5-10% bigger because of optimizations from -O2 to -O3, these means for most binaries an increasement of 100Kb. believe me, it takes longer for the hdd to search the chunks on the drive than to load it actually (hdd's today read about 30-40mb per second but seeking and sequential read/write is quite slow).
the problem with bigger binaries mostly lies in bigger cache usage which is quite limited (even though 256kb to 512kb is quite much).

fourth: march activates mmx sse and 3dnow if appropriate, so don't care about these flags except you don't use march.

fifth: in nbench and freebench i get a performance increasement of 3-4% with -mfpmath=sse on an athlon-xp in comparison of i387 (which is the default). sse has only a precision of 64bit so it can only be used for floats not for double (which is mostly used), so you mostly don't see a big improvement, even though gcc-3.3 and 3.4 don't use sse in vectorize mode (gcc-4.0 will use it). to use i387 and sse in parallel doesn't gain much (nearly nothing) and is very risky, i wouldn't use it. sse2 with its 128bit precision is more precise than i387 with a maximum of 80bit and has fewer problems with exceptions, gcc devels mostly prefer to use sse2 as i remember but some sse2 instructions are buggy, so hope for a fix.

[Warped_Dragon]

1) I'm well aware of that. I wasn't asking for a 'perfect' set of flags that would give every program I run a 500% speedboost. Or even a 10% speedboost. Or 0.2%. *reads over his first post* Wait a tic, I wasn't asking for a 'perfect' set of CFLAGS at all, just if my current ones were taking full advantage of the different optimization options supported by my CPU. I'll assume your first comment wasn't directed at me. Many apologies

2) Thank you. This is the only AMD system I've ever used, all my experiance is with Intel. Now I've got one suggestion for -march=athlon and one for -march=athlon-xp. Can you point me to some documentation so I can confirm/deny this myself? In fact, I'll start at the AMD site.

EDIT - Found something. Quote is from http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_1260_1202%5E1018,00.html#9947

[Nate_S]

While doing your reasearch you'll want to look at what core your proc is based on. I believe Palimino (sp?) is the first athlon xp core, that's what's in my athlon-xp 1800, if it's not that it's prolly an athlon.

Yes, generally -O3 is considered by most to be faster than -Os or -O2. also, I think -funroll-loops (though not -funroll-all-loops,) is also worth it.

I'd like to point out that redundant flags really don't hurt anything.

As I mentioned, wheather 387 or sse was better on the athlon would depend heavily on the type of app used, I don't know that a benchmark would give a good overall estimate.

Also, sse2 is only on P4s and 64 bit AMD chips, right? Or did some of the later athlon-xps have it?

-Nate

[chickaroo]

[LockeAverame]

your duron has sse support, so it's a morgan core which is derived from a palomino core but with fewer cache (64kb instead of 256kb L2-cache), that's the only difference ( the older athlons didn't have sse like the durons in those days ^^). -march=athlonx-p works perfectly (i had this duron myself, so believe it). if you don't want to believe it than read the white papers for your stepping of the cpu (cat /proc/cpuinfo will tell you the stepping).
sse2 was never available for athlon-xp and beneath, it was first integrated with the k8 (opteron/athlon64), if people think this is wrong than they say bullshit.
well, no benchmark can test every possible codesnippet available. i used nbench and freebench and both give a 3-4% increasement with -mfpmath=sse and nothing higher with -mfpmath=sse,387.
only apps which use float (rarely used in standard software, more often used in games and codecs).
redundant flags don't hurt but don't do anything sensefull either, only polluting your bashoutput in compilations ^^.

[headgap]

ok, my two cents. from a developer. yes, i know it says n00b, but trust me,
i'm a developer :)

the nice thing about being a 'retired' developer, you get to find bugs, and
not be obliged to fix them...

here's the deal with speed optimizations:

there's an old saw in the industry: programs spend 90% of their time in 10%
of the code. there's no point trying to optimize the other 90% of the code, it
won't get you any advantage. developers typically take the stand-point:
simpler is better, and don't do any optimization until release-time.

when it comes to optimizing code, you can: a) use a better (faster) algorithm,
b) code bits in assembler, c) do both. i once wrote a message passing queue
based system entirely in pentium assembler (about 20k of asm, vs 120k of C).
it ran 10x faster than the portable C code did, and tripled the development
time.

if you take a really close look at the compile process for the sources, you'll
notice individual packages very selectively using additional compile flags,
such as glibc: -freorder-blocks. this is the developer's way of descending in
a portable manner partially to the assembler level. gaming code and real-time
instrumentation contain way more assembler, and device drivers are almost
pure assembler: because that's where speed counts.

any program requiring feedback from the user, or that needs to hit slow
storage (disk systems, networks) won't benefit significantly from speed optimization (meaning, more than 10-15% increase).

*unless*

it's development code, the bugs are still being worked out, the code base
hasn't been finalized yet, so it doesn't make sense to optimize, since it might
get thrown away eventually.

since gentoo is providing bleeding edge packages, using higher levels of
optimization will tend to a) give that 10% increase, and b) break things.

since you're not the developer of the package, and have no idea what sort of code is being used, you can't pick the one or two special flags that would
make that code really fly. the best you can hope for is apply 'everything', and cross your fingers. optimizations that work for some code, won't do a thing for the next package. but in general, you'll see some sort of
improvement, on average, since the underlying code isn't already optimized.

so,

-O2 for CPUs with large L1 cache, -Os for those earlier ones (Coppermine and lower) with less L1.

-march if you don't need portable code will select hardware-only features appropriate to your cpu

-ffast-math at your own peril, if you do anything with double-precision
floating point (financials, spreadsheets, DV, imaging, mJpegTools, et al)

and, selectively, very specific individual flags based on the nature of the source, on a per-file basis, if you know what you're trying to achieve, and
need your optimization to be as platform transparent as possible.
_________________
If at any time you find yourself on the side of the majority, it is time to reconsider your position - Mark Twain

[evilshenaniganz]

I've been having a helluva time with a K6-2 of mine. I would really like to get as much optimization out of it as I can. I notice I often have builds fail when I use

[evilshenaniganz]

Hey, it's me again...

I figure if I'm coming with a problem, I better bring something else to the table. I noticed a lot of people are asking about resources for finding out more about CFLAGs. Well, apart from Ye Olde CFLAGS Central, I have also found a few pages that might help someone out. Here they are:

http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

HTH

[schiznik]

Wow, I'm surpised no-one has mentioned the gentoo-wiki page http://gentoo-wiki.com/Safe_Cflags yet.

I use

[idahoduk]

[ebfe]

moderators should delete or at least close such threads as ALL of what has been posted here about cflags is bogus information and give no speed increase at all. Read this last sentence again.