CFLAGS Central (Part 2)

[nxsty]

I just upgraded to gcc-4.1.1 which is now ~x86 in portage and stumbled over the LDFLAGS I setted before. After some research I got it working, but still I just don't really know what I'M doing here, so if anyone does I'd appreciate his recommodation regarding LDFLAGS and CFLAGS for my system. I have a 1,8 GHz Pentium 4M Laptop

I'll you whatever you also need to know if you ask! Thanks in advance!!!

Try with:
CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1"

[nxsty]

hi,

quite a newb question (sorry, I am leraning ): if I change some CFLAG, I will need to do an emerge -e --deep system and a emerge -e --deep world.
so, will EVERYTHING on my system will be compile, ie, will it be the same thing as if I had set those flag during a stage 1 install?

I am also thinking to use the same flags as Vipenicus:

Code: Select all

CHOST="i686-pc-linux-gnu"
#
CFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2"
CFLAGS="${CFLAGS} -pipe"
CFLAGS="${CFLAGS} -Os"
CFLAGS="${CFLAGS} -fomit-frame-pointer"
CFLAGS="${CFLAGS} -fstack-protector-all"
CFLAGS="${CFLAGS} -fno-ident"
CFLAGS="${CFLAGS} -fforce-addr"
CFLAGS="${CFLAGS} -ftracer"
CFLAGS="${CFLAGS} -fweb
CFLAGS="${CFLAGS} -falign-functions=4"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
#
LDFLAGS="-Wl,-O1 -Wl,--sort-common" 

is it safe with gcc 4.1.1?

thanks

Remember that -fstack-protector-all will reduce your performance. -ftracer is also mostly pointless and usually only makes code slightly slower and larger. If I where you I'd use -march=pentium4 -O2/-Os -fomit-frame-pointer -pipe. It might save you some problems and you wouldn't notice any difference what so ever (except if you're comparing to a system compiled with -fstack-protector-all which probably would be a bit slower).

[Ray ishido]

nxsty, Thank you for your answer. I will follow your advise.
Do you think it's ok for the LDFLAG?

[Edit]: sorry, I hadn't read your answer to _loki_. I will use LDFLAGS="-Wl,-O1"

[Marel]

Maybe we should learn from this:

http://getswiftfox.com/rel-athlon-xp.htm

One can see all parameters used for compilation, and I can tell you that I compared its speed with Gentoo emerged version and that it was 22.5% faster If you don't believe this, check it yourself.

EDIT: I measured loading time of mysql 4.0.23a manual.
EDIT2: this link is athlon-xp version if you have another CPU, there are other versions for download.

[nxsty]

Maybe we should learn from this:

http://getswiftfox.com/rel-athlon-xp.htm

One can see all parameters used for compilation, and I can tell you that I compared its speed with Gentoo emerged version and that it was 22.5% faster If you don't believe this, check it yourself.

EDIT: I measured loading time of mysql 4.0.23a manual.
EDIT2: this link is athlon-xp version if you have another CPU, there are other versions for download.

What benchmarks did you run to find out it was 22,5% faster? It's not really comparable btw if you don't use the exact same mozconfig settings. For example gentoo enables cairo support by default and that build you linked to don't it seems.

[Marel]

What benchmarks did you run to find out it was 22,5% faster? It's not really comparable btw if you don't use the exact same mozconfig settings. For example gentoo enables cairo support by default and that build you linked to don't it seems.

As I sad, I measured loading time of mysql 4.0.23a manual. It was 7.1s vs 8.8s or something.

[Skrot]

I was looking through the GCC manual for other optimisation options which might affect 3D rendering performance, and came across the -mfpmath=sse option. From reading the manual, this option sounds purely like a good one.

The resulting code should be considerably faster in the majority of cases and
avoid the numerical instability problems of 387 code, but may break some existing
code that expects temporaries to be 80bit.

But I've only seen people saying that it nearly always makes code slower. Why such a big discrepency between the GCC manual and what people seem to be saying? The "avoid the numerical instability problems of 387 code" sounds good just on its own. Not that I know what the problem with 387 code is, however.

Edit: I should probably say that I'm using an Athlon XP 2800+.

[yngwin]

The -mfpmath options don't seem to work as they should. I've only ever seen the recommendation not to use them.

[lnxz]

Using both sse and 387 is broken, at least.
In theory sse fpmath is quite nice, but I think I've read somewhere that in practice it depends on your cpu. In any event one should let the compiler decide, unless you know the compiler is wrong.

[weaksauce]

so, nxsty, I noticed you have an amd64 system, so what LDFLAGS would you suggest for that? (running the system in 64-bits)

EDIT: I use KDE too, if that matters

[TheCoop]

does anyone know the status of -fvisibility=hidden and -fvisibility-inlines-hidden?

[enderandrew]

I am also thinking to use the same flags as Vipenicus:

Code: Select all

CHOST="i686-pc-linux-gnu"
#
CFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2"
CFLAGS="${CFLAGS} -pipe"
CFLAGS="${CFLAGS} -Os"
CFLAGS="${CFLAGS} -fomit-frame-pointer"
CFLAGS="${CFLAGS} -fstack-protector-all"
CFLAGS="${CFLAGS} -fno-ident"
CFLAGS="${CFLAGS} -fforce-addr"
CFLAGS="${CFLAGS} -ftracer"
CFLAGS="${CFLAGS} -fweb
CFLAGS="${CFLAGS} -falign-functions=4"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
#
LDFLAGS="-Wl,-O1 -Wl,--sort-common" 

is it safe with gcc 4.1.1?

thanks

The GCC 4.1.1 manual doesn't even seem to list an option for -fno-ident anymore, and that flag may have been dropped.

Personally, I've experimented with various CFLAGS, and I'm dropping -ftracer. I've found that most flags increase compile time and don't really help performance. I have seem some dynamic improvements from various LDFLAGS and that is where I'm experimenting more these days.

With all that being said, a CFLAG has caught my eye. Does anyone have any experience playing with the following:

-freorder-blocks-and-partition
In addition to reordering basic blocks in the compiled function, in order to reduce number of taken branches, partitions hot and cold basic blocks into separate sections of the assembly and .o files, to improve paging and cache locality performance.

This optimization is automatically turned off in the presence of exception handling, for linkonce sections, for functions with a user-defined section attribute and on any architecture that does not support named sections.

[bur]

It's been quite a while since I did a full update of my system, so I was wondering if there are any news on the cflags-front...

I have a Duron Morgan, which is identical to an Athlon XP when it comes to compiling.

CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
LDFLAGS="-Wl,-O1"

Is there anything I could/should change to get better performance or stability?


Also I wonder if someone already did a run with Acovea for an Athlon XP and can say what cflags it suggests as being fastest.

[enderandrew]

It's been quite a while since I did a full update of my system, so I was wondering if there are any news on the cflags-front...

I have a Duron Morgan, which is identical to an Athlon XP when it comes to compiling.

CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
LDFLAGS="-Wl,-O1"

Is there anything I could/should change to get better performance or stability?


Also I wonder if someone already did a run with Acovea for an Athlon XP and can say what cflags it suggests as being fastest.

I'm doing a new install right now on an athlon-xp laptop and intentionally trying to break my system to see which LDFLAGS and CFLAGS break which packages. And while I normally completely trust nxsty's opinion, I think I might give profiles a try.

It does seem to be perfectly suited from Gentoo, at least from what the GCC manuals reads to me.

-fprofile-generate
Enable options usually used for instrumenting application to produce profile useful for later recompilation with profile feedback based optimization. You must use -fprofile-generate both when compiling and when linking your program.

The following options are enabled: -fprofile-arcs, -fprofile-values, -fvpt.

Obviously, we use our computers, and we recompile when new versions come out. Why not generate profiles so that the next compile will be automatically more optimized? Is there a reason not to use this that I'm not aware of?

Code: Select all

CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -ftracer"
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 -Wl,-Bdirect"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-Bdirect -Wl,-hashvals -Wl,-zdynsort"

Again, as you can see, I'm purposely trying to see what LDFLAGS especially break what packages. If only a few packages break with certain flags, then I will filter then with a packages.ldflags file and a bashrc script. If tons break because of a certain flag, then I'll remove it. But individually, people seem quite happy with --sort-common, --as-needed, -Bdirect, -hashvals and -zdynsort. Why not be stupid and try them all?

[lnxz]

The GCC 4.1.1 manual doesn't even seem to list an option for -fno-ident anymore, and that flag may have been dropped.]

-fno-ident is in the code generation section of the manual, as it's not exactly an optimisation, it just removes/inhibits the adding of the .ident section of the binary (if I've understood it correctly, that is)..

[enderandrew]

So, is that practical for everyday use? Is there good reason to use or not use that flag in make.conf?

[lnxz]

AFAIK the .ident section has no practical use, thus disabling it shouldn't do any harm, neither will it alter compile times. It will, however, save you a miniscule amount of bytes.

[bur]

While reading about the different features of GCC I noticed that it seems to be unclear whether -O2 implies -fomit-frame-pointer or not.

The man pages for gcc say: "-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging." So that'd mean to be sure frame pointer get omitted you need to explicitly state it (at least if on your arch it interferes with debugging, does this apply for x86?).

But man gcc also say: "-O2 turns on all optimization flags specified by -O." Does that mean when using -O2 -fomit-frame-pointer is used no matter what or is the condition from -O still active?

Okay, it's not that important, as adding -fomit-frame-pointer to your CFLAGS isn't much work, but I'd still like to know.

[lnxz]

I think I've read somewhere that -O2 doesn't include fomit-frame-pointer on x86.

[bur]

lnxz,
maybe then x86 is one of the architectures where debugging gets impossible with -ffp and thus it isn't included in -O/2/3.

[yngwin]

That is indeed the case.

[VinzC]

Hi.

I have an AMD64 - model name AMD Athlon(tm) 64 Processor 3200+ - and I wondered what CFLAGS were best for it. I didn't find anything relevant on Safe Flags - Gentoo Wiki and /etc/make.conf currently lists

Code: Select all

CFLAGS="-march=k8 -O3 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"

I think the "-march=k8" came with the LiveCD I used and I left it as is. So I wondered if K8 is for Athlon what i386 is for Intel, i.e. generic. I "feel" my machine is not as fast as it could be though. So is there a CFLAGS I can use, say -march=athlon64? Or should I stay with -march=k8?

For your info:

Code: Select all

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 0
cpu MHz         : 2000.143
cache size      : 512 KB
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 pni lahf_lm
bogomips        : 4009.64
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

EDIT: Consider I'm about to switch to -O2. But my question still remains.

[lnxz]

k8 seems to be usable with any k8 core based cpu, so it might be a little generic, so perhaps athlon64 would be more appropriate in your case.

[VinzC]

Thanks a lot lnxz. Going for emerge -ave world ...

[lnxz]

Imho it's not really worth doing a complete rebuild.
You should at least investigate the differences between athlon64 and opteron/athlonFX (or whatever other k8 based cpus are out there) to see if the athlon64 flag really enables any cool features that k8 doesn't.