CFLAGS Central (Part 2)

Message

VinzC · Post by **VinzC** » Sun Jul 02, 2006 3:50 pm

I'm no Linux developer in fact but I guess what you mean is to search man gcc?

lnxz · Post by **lnxz** » Sun Jul 02, 2006 5:27 pm

Well, if you choose to do rebuild everything, you might end up having wasted a lot of time for nothing.
The gcc manual doesn't really point out any differences, as far as I could see, however I'm sure there are others on these forums who knows a lot more about this than me.

VinzC · Post by **VinzC** » Sun Jul 02, 2006 7:39 pm

There are a couple of packages which USE flags are in parentheses, like (3dnow) or (sse). I've checked portage manual and it says the current profile is responsible for that and these flags cannot be used with the current profile. How can I know which profile to switch to for these flags to be used? Are they unsafe?

lnxz · Post by **lnxz** » Sun Jul 02, 2006 8:41 pm

What profile might that be?
Personally neither of those flags have caused any problems (that I've been able to notice).

Don-DiZzLe · Post by **Don-DiZzLe** » Sun Jul 02, 2006 10:13 pm

Hello everyone,

I am going to read through this thread and Part 1 but that;s gonna take while so until then what do y'all think about my flags:

Code: Select all

-march=athlon64 -msse3 -pipe -O2 -fno-ident -fforce-addr -fomit-frame-pointer -funroll-loops

Any suggestions for further optimization?

This is my pocessor:

Code: Select all

cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 8
cpu MHz         : 800.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow ts fid vid ttp
bogomips        : 1609.09

+ 1024 megs of DDR memory.

VinzC · Post by **VinzC** » Sun Jul 02, 2006 11:32 pm

lnxz wrote:What profile might that be?
Personally neither of those flags have caused any problems (that I've been able to notice).

Well I don't know what profile at all. All I know is that these flags are not used despite I set them in make.conf. But I don't know if they have anything to do with CFLAGS and GCC optimizations...

lnxz · Post by **lnxz** » Sun Jul 02, 2006 11:43 pm

They are related to gcc. Some packages, like mplayer, are very picky about cflags. 3dnow/sse/mmx useflags allow these packages to use cflags that would otherwise be ignored/disabled.
To see what profile you're using, try 'readlink /etc/make.profile'.

bur · Post by **bur** » Mon Jul 03, 2006 3:39 am

About your cflags, I sometimes read that you have to be careful with -funroll-loops as it makes the execs much bigger which can lead to slower performance on systems with little cache (don't know if that applies to the Athlon64). All in all it seems though as besides -O2|3|s, -march=xxx and pipe most flags don't have a big impact on the performance.

Some people did run tests with different sets of cflags with lame and judged the cflags on encoding speed. This might give an estimate which flags are good and which aren't. On the other hand, utils such as lame perform very specific taks so what flags might be good for them might be bad for other progs.

After some playing around with cflags/ldflags I'm now using "CFLAGS=-O2 -march=athlon-xp -fomit-frame-pointer -pipe". Maybe some exotic flag might give me 0.01% more speed with a specific app, but I don't think that's worth testing for hours.

Don-DiZzLe · Post by **Don-DiZzLe** » Mon Jul 03, 2006 12:46 pm

OK here's a little script that I use:

Code: Select all

#!/bin/bash
# fs2_open Compile Script
# These are only examples, uncomment to enable optimization.
MY_CFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -msse3 -fno-ident -freorder-blocks-and-partition -ftracer -fvisibility-inlines-hidden -fno-enforce-eh-specs"
if [ -e ./fs2_open/ ];
	cd fs2_open
	if [ -e ./Makefile.in ]; then
	make clean
	./configure CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS"
	make
	else
	./autogen.sh CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS"
	make
	fi
	else
	echo "No fs2_open directory found."
fi

So in order to use the LDFLAGS I need to edit my script to somethin like this:

Code: Select all

#!/bin/bash
# fs2_open Compile Script
# These are only examples, uncomment to enable optimization.
MY_CFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -msse3 -fno-ident -freorder-blocks-and-partition -ftracer -fvisibility-inlines-hidden -fno-enforce-eh-specs"
MY_LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common"
if [ -e ./fs2_open/ ];
	cd fs2_open
	if [ -e ./Makefile.in ]; then
	make clean
	./configure CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS" LDFLAGS="$MY_LDFLAGS"
	make
	else
	./autogen.sh CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS" LDFLAGS="$MY_LDFLAGS"
	make
	fi
	else
	echo "No fs2_open directory found."
fi

Is this correct?

Do I need to add some more optimizations or will this do it?

lordlouf · Post by **lordlouf** » Sun Jul 09, 2006 11:05 am

Hi,

after looking ar this subject (part 1 and 2), I have question regarding my configuration. I currently have a server with a Celeron D 64bits. My current CFLAG is set to "-O2 -pipe -march=k8".

Should I switch to another or not ?

Thank you

enderandrew · Post by **enderandrew** » Sun Jul 09, 2006 11:58 am

I'm pretty sure k8 is the wrong arch for the Celeron D series. The k8 arch is for Semperon/Athlon 64/Opteron processors.

As far as CFLAGs, if you ask ten people you'll hear at least 5 different things.

You currently have very stable (though boring) flags. There is nothing wrong with them.

Personally, I'd go with something like the following:

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
CXXFLAGS="${CXXFLAGS} -ffriend-injection"
CXXFLAGS="${CXXFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed"

This is fairly sane, and not a huge deviation from what you're running now. I know some people also claim to have decent results adding -ftracer and -fweb but I've tried them and I couldn't tell either way.

The reason I have the two CXXFLAGS on other lines is that if I ever run into a package where one of these doesn't work (considerably less often these days) I can easily comment that line out.

If you try nxsty or nesl's overlays, then you can also use some other LDFLAGS. Personally, I'm a big fan of them.

Also check to see what instructions your processor supports. It should support mmx sse and sse2, all three of which could then be added to your USE flags.

Dr.Dran · Post by **Dr.Dran** » Sun Jul 09, 2006 12:45 pm

enderandrew wrote:CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
CXXFLAGS="${CXXFLAGS} -ffriend-injection"
CXXFLAGS="${CXXFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed"

...The reason I have the two CXXFLAGS on other lines is that if I ever run into a package where one of these doesn't work (considerably less often these days) I can easily comment that line out...

Hi, I'm not a lamer o a troll, but I want to suggest you to utilize that version of portage bashrc that me and my frinds are developing.
This is the post where you can download the program, there is a module that we have called perpackage that give you the possibility to set the CFLAGS/CXXFLAGS/LDFLAGS for a particulare package.

Another questions what versin of gcc do you utilize? The 4.1.1?

Cheers

Franco Tampieri

enderandrew · Post by **enderandrew** » Sun Jul 09, 2006 1:32 pm

I do use your bashrc script. However, lately I moved all my package.* files and I'm trying to see what breaks and I really need to filter, because many packages that I filtered for --as-needed before work fine with --as-needed now.

I use GCC 4.1.1 SVN with the UCLIBC and PIE patches.

lordlouf · Post by **lordlouf** » Sun Jul 09, 2006 2:41 pm

enderandrew wrote:I'm pretty sure k8 is the wrong arch for the Celeron D series. The k8 arch is for Semperon/Athlon 64/Opteron processors.

As far as CFLAGs, if you ask ten people you'll hear at least 5 different things.

You currently have very stable (though boring) flags. There is nothing wrong with them.

Personally, I'd go with something like the following:

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"

This is fairly sane, and not a huge deviation from what you're running now. I know some people also claim to have decent results adding -ftracer and -fweb but I've tried them and I couldn't tell either way.

The processor is 64bit capable, so the Host is set to "x86_64-pc-linux-gnu" and does the arch "prescott" enables 64bits capacities ?

thank you

Dr.Dran · Post by **Dr.Dran** » Sun Jul 09, 2006 2:51 pm

enderandrew wrote:I use GCC 4.1.1 SVN with the UCLIBC and PIE patches.

Why did yuo use the uclibc instead the normal glibc?

lordlouf · Post by **lordlouf** » Fri Jul 14, 2006 5:34 pm

I finally found that for a Celeron D, it is recommanded to set arch to "nocona". it's working quite well.

Tikikatra · Post by **Tikikatra** » Fri Jul 14, 2006 9:43 pm

man gcc says:

Code: Select all

 -fomit-frame-pointer
           Don't keep the frame pointer in a register for functions that don't
           need one.  This avoids the instructions to save, set up and restore
           frame pointers; it also makes an extra register available in many
           functions.  It also makes debugging impossible on some machines.

           On some machines, such as the VAX, this flag has no effect, because
           the standard calling sequence automatically handles the frame
           pointer and nothing is saved by pretending it doesn't exist.  The
           machine-description macro "FRAME_POINTER_REQUIRED" controls whether
           a target machine supports this flag.

           Enabled at levels -O, -O2, -O3, -Os.

Enabled at levels -O, -O2, -O3, -Os. So what is the point in adding it to your CFLAGS?

Edit: got an answer in the IRC channel:
x86 does not imply the flag cause it breaks debug info.

peka · Post by **peka** » Thu Aug 24, 2006 5:32 pm

lordlouf wrote:I finally found that for a Celeron D, it is recommanded to set arch to "nocona". it's working quite well.

Where did you find this?

vovin · Post by **vovin** » Thu Aug 24, 2006 7:41 pm

-O3 --param max-inline-insns-single=48 --param max-inline-insns-auto=48 -g0
-march=prescott -mfpmath=sse -fomit-frame-pointer
-funroll-loops --param max-unrolled-insns=48

gcc 3.4.6

Celeron M Yonah

AnXa · Post by **AnXa** » Sun Sep 03, 2006 4:27 pm

I know that if I change my CFlags from -o3 ro -os I have to recompile my whole system again. So how I can do it? I know that I have to force emerge to do it somehow. I am running amd64. And I am planning to change my -O3 to -OS. Thank you.

I followed AMD Recomentation when I installed my gentoo like one and half years ago. But I started to look it into and noticed that Athlon64 systems with -os perform a lot better. and memory comsuption is pretty high on my computer. plus I cannot allways debug my own programs well. lol...

My CFlags:

Code: Select all

CFLAGS="-O3 -march=athlon64 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -fomit-frame-pointer -pipe"

As seen in here: http://forums.gentoo.org/viewtopic-t-257417.html

Note that I haven't yet upgraded GCC into 4.1 which was marked stable recently on amd64 platform. So I guess I have to recompile my gentoo anyway at somepoint.

nixnut · Post by **nixnut** » Sun Sep 03, 2006 4:39 pm

merged above post here.

AnXa · Post by **AnXa** » Sun Sep 03, 2006 5:08 pm

aah, f*** em'. I'll be adventurous and but -Os into my CFlags and recompile system with GCC4.1.1. Let's see what happens...

EDIT: OMG! I was just told that MacOSX is optimized with -Os!!

Can you belive it! Apple optimizes for size and not for full speed.

CosminG · Post by **CosminG** » Mon Sep 04, 2006 6:11 am

I have one question. Since I want to stick to x86 cand I use for my processor:

Code: Select all

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 44
model name      : AMD Sempron(tm) Processor 2600+
stepping        : 2
cpu MHz         : 1607.852
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts ttp tm stc
bogomips        : 3218.43

these settings

Code: Select all

CFLAGS="-march=athlon64 -msse3 -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

nxsty · Post by **nxsty** » Mon Sep 04, 2006 7:08 am

CosminG wrote:I have one question. Since I want to stick to x86 cand I use for my processor:

Code: Select all

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 44
model name      : AMD Sempron(tm) Processor 2600+
stepping        : 2
cpu MHz         : 1607.852
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts ttp tm stc
bogomips        : 3218.43

these settings

Code: Select all

CFLAGS="-march=athlon64 -msse3 -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

Yes, that´s what I would use.

nxsty · Post by **nxsty** » Mon Sep 04, 2006 7:35 am

AnXa wrote:aah, f*** em'. I'll be adventurous and but -Os into my CFlags and recompile system with GCC4.1.1. Let's see what happens...

EDIT: OMG! I was just told that MacOSX is optimized with -Os!! Can you belive it! Apple optimizes for size and not for full speed.

It wouldn´t suprise me. Apple probably optimize with what they think is appropriate for the situation. Most apps doesn´t benefit from performance optimizations. What matters is binary size as smaller binaries loads faster, uses less memory etc. So -Os would be the fastest and -O3 the slowest and other optimizations that also bloats would slow down further (-funroll-loops etc). There are some exceptions like image/audio/video decoders and such that runs better when they´re optimized for performance.

CFLAGS Central (Part 2)

CFlags and world recompiling...