| View previous topic :: View next topic |
| Author |
Message |
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
 Posted: Sun Jun 12, 2005 5:53 pm Post subject: |
 |
|
Now I'm here again to guess all of you to discuss my CFLAGS, CXXFLAGS and LDFLAGS that I have in mind to apply ti my system to improve a little the performance and have a lot of stability:
N.B. Actually I use the GCC 3.3.5 version
| Code: | | CFLAGS="-O2 -march=athlon-mp -finline-functions -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -pipe" |
| Code: | | CXXLAGS="${CFLAGS} -fno-rtti" |
| Code: | | LDFLAGS="$LDFLAGS -Wl,-O1 -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--sort-common" |
I'm not sure for the -finline-functions in the CFLAGS and the -fno-rtti in the CXXFLAGS, but I read that:
| Code: | -finline-functions = Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth integrating in this way. If all calls to a given function are integrated, and the function is declared `static', then the function is normally not output as assembler code in its own right. Enabled at level `-O3'.
-fno-rtti = Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (`dynamic_cast' and `typeid'). If you don't use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. |
And I'm doubt for the LDFLAGS configuration that I have readed in some Forums:
https://forums.gentoo.org/viewtopic-t-316445-highlight-asneeded.html
https://forums.gentoo.org/viewtopic.php?t=231170
I think that make the code not very stable and brake some compilation. Does anyone have a suggestion or consideration to my settings?  
Have a Good Hacking!!!  |
|
| Back to top |
|
 |
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Mon Jun 13, 2005 11:25 am Post subject: |
|
|
| DranXXX wrote: | | Does anyone have a suggestion or consideration to my settings? |
Yes. Read my posts on this thread.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Thu Jun 16, 2005 7:30 pm Post subject: |
|
|
ok!, I have readed your post, and I think in the end that the best settings is:
| Code: | | CFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -pipe" |
And il I have a gcc 3.4.x or 4.x
| Code: | | CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden" |
But i have a question...
In the man gcc I found that lines:
| Quote: | | -fvisibility-inlines-hidden = Causes all inlined methods to be marked with __attribute__ ((visibility ("hidden"))) so that they do not appear in the export table of a DSO and do not require a PLT indirection when used within the DSO. Enabling this option can have a dramatic effect on load and link times of a DSO as it massively reduces the size of the dynamic export table when the library makes heavy use of templates. While it can cause bloating through duplication of code within each DSO where it is used, often the wastage is less than the considerable space occupied by a long symbol name in the export table which is typical when using templates and namespaces. For even more savings, combine with the -fvisibility=hidden switch. |
And next I read this:
| Quote: | -fvisibility=default|internal|hidden|protected
Set the default ELF image symbol visibility to the specified option—all symbols will be marked with this unless overridden within the code. Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute.
Despite the nomenclature, default always means public ie; available to be linked against from outside the shared object. protected and internal are pretty useless in real-world usage so the only other commonly used option will be hidden. The default if -fvisibility isn't specified is default, i.e., make every symbol public—this causes the same behavior as previous versions of GCC.
A good explanation of the benefits offered by ensuring ELF symbols have the correct visibility is given by “How To Write Shared Libraries” by Ulrich Drepper (which can be found at http://people.redhat.com/~drepper/)—however a superior solution made possible by this option to marking things hidden when the default is public is to make the default hidden and mark things public. This is the norm with DLL's on Windows and with -fvisibility=hidden and __attribute__ ((visibility("default"))) instead of __declspec(dllexport) you get almost identical semantics with identical syntax. This is a great boon to those working with cross-platform projects.
For those adding visibility support to existing code, you may find `#pragma GCC visibility' of use. This works by you enclosing the declarations you wish to set visibility for with (for example) `#pragma GCC visibility push(hidden)' and `#pragma GCC visibility pop'. These can be nested up to sixteen times. Bear in mind that symbol visibility should be viewed as part of the API interface contract and thus all new code should always specify visibility when it is not the default ie; declarations only for use within the local DSO should always be marked explicitly as hidden as so to avoid PLT indirection overheads—making this abundantly clear also aids readability and self-documentation of the code. Note that due to ISO C++ specification requirements, operator new and operator delete must always be of default visibility.
An overview of these techniques, their benefits and how to use them is at http://www.nedprod.com/programs/gccvisibility.html. |
But where i can put that options? And May I improve that configuration?
Thanx
Edit: ehm excuse me I have read that post https://forums.gentoo.org/viewtopic-t-303068-highlight-fvisibility.html and I have found the answer for my last question... but I want to know a think... Moocha do you use Gnome?  Because I use It too |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Fri Jun 17, 2005 6:29 am Post subject: |
|
|
| DranXXX wrote: | ok!, I have readed your post, and I think in the end that the best settings is:
| Code: | | CFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -pipe" |
|
Sounds good. I'd get rid of -fforce-addr, but it's your choice.
Don't use the visibility flags at all. -fvisibility is highly evil, and -fvisibility-inlines-hidden has also been lately shown to break things. | DranXXX wrote: | | Moocha do you use Gnome? Because I use It too |
Nope, fluxbox.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Fri Jun 17, 2005 1:18 pm Post subject: |
|
|
| moocha wrote: | | DranXXX wrote: | ok!, I have readed your post, and I think in the end that the best settings is:
| Code: | | CFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -pipe" |
|
Sounds good. I'd get rid of -fforce-addr, but it's your choice.
Don't use the visibility flags at all. -fvisibility is highly evil, and -fvisibility-inlines-hidden has also been lately shown to break |
What breakage are you talking about? The only problems i know of was on amd64 and ppc with -fvisibility-inlines-hidden breaking kde but that's fixed in gcc-3.4.3.20050110-r1 and later (bug #78720). Or are there anything else? |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Sun Jun 19, 2005 3:26 pm Post subject: |
|
|
Yeah that's cool, i have removed the -fforce-addr on the CFLAGS and I compile it on the notebook of my brother, and for now there isn't any problem, the system works, and I'm happy
...another special questionz:
Do you think that may compile a new gentoo with the flag "USE=pic ntpl ntplonly" enable to compile the glibc one time? Do you know if there is some problems?
thanx |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Sun Jun 19, 2005 3:37 pm Post subject: |
|
|
Use nptlonly at your own risk. I don't use it since I rely heavily on Sun's JDK, and nptlonly plays hob with certain third-party software.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Sun Jun 19, 2005 4:00 pm Post subject: |
|
|
| moocha wrote: | | Use nptlonly at your own risk. I don't use it since I rely heavily on Sun's JDK, and nptlonly plays hob with certain third-party software. |
That's good, thanx for the support that you give to me! |
|
| Back to top |
|
|
Plazmic
n00b
Joined: 18 Feb 2005
Posts: 34
Location: Florida
|
| Posted: Tue Aug 09, 2005 2:21 am Post subject: |
|
|
Excellent thread!
While I am willing to suffer the increased compile time for the minute speed increase of optimizing via -O3. I am concerned that -finline-functions, -fweb and -frename-registers may perhaps be known to break things? I wasn't able to find any information regarding the issue so anyone's personal experience would be helpful.
In otherwords, will using -O3 cause any major problems other than up to a 30% increase in compilation time?
EDIT:
My current make.conf:
| Code: |
CHOST="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -fomit-frame-pointer -momit-leaf-frame-pointer"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
and the rest of my portage settings.
I'm using GCC 3.4.4 but don't feel that the benefits of any LDFLAGS are worth the increased risk of breakage. |
_________________
..::I reject your reality and substitute my own::.. |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Tue Aug 09, 2005 7:04 am Post subject: |
|
|
| Plazmic wrote: | | In otherwords, will using -O3 cause any major problems other than up to a 30% increase in compilation time? |
Hi! The advantages of using -O3 instead -O2 are very minimal, and some programs with the -O3 won't compile nicely, I have a system compiled with the -Os flags because I have a dual Athlon MP, but my brother have a mobile Pentium IV on his notebook and have compiled clean all the system with the -O2, the system result very stable and both KDE and Gnome run's well!!!
N.B. Note that the option CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden" has recently known that was buggy, don't use it on that version of GCC
Bye |
|
| Back to top |
|
|
Plazmic
n00b
Joined: 18 Feb 2005
Posts: 34
Location: Florida
|
| Posted: Tue Aug 09, 2005 2:47 pm Post subject: |
|
|
Thanks for the input. I have only read that -fvisibility-inlines-hidden previously caused problems with KDE but was fixed. I have also heard of problems with -fvisibility but failed to find any good documentation on it. For now I'm staying away from it and rebuilding my system. However, any further details would be appreciated.
_________________
..::I reject your reality and substitute my own::.. |
|
| Back to top |
|
|
Dominique_71
Veteran
Joined: 17 Aug 2005
Posts: 1877
Location: Switzerland (Romandie)
|
| Posted: Wed Aug 30, 2006 1:40 pm Post subject: |
|
|
Thank you for the informations on this thread.
I have now the following flags: | Code: | CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fforce-addr -fno-ident -ftracer"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--sort-common" |
That's with gcc 3.4.6. The result is a very stable system, the -fforce-addr is doing good with -O3, but the problem I get with it is at the resulting code is not faster as with -O2 alone, and still is bigger and take more time to compile. So I will get back to -O2, because I just don't have the time to test all my program to know when it is safe to use -O3 without -fforce-addr, and when I must add -fforce-addr. I done the test with the nec2 antenna simulation software (not in portage), and -O2 is just better because it will compile faster and load faster as the same program compiled with -O3 -fforce-addr.
The main uses for my box are audio and electronic simulation. I am planing to change my flags at the same time at I will upgrade to gcc4.
It is a few new flags with gcc, but it is hard to find reliable information about what they are doing. As exemple, about -ftree-vectorize, we can read in the gcc4.1 manual: | Quote: | -ftree-vectorize
Perform loop vectorization on trees. |
It is not much. This option is not in any -O flag, and it is no warning of any kind. I thing at it will be safe and at it can be a good thing to have on a system that use audio and scientific program. I am thinking to use something as | Code: | CFLAGS="-O2 -march=pentium4 -pipe -fweb -ftree-vectorize -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--sort-common" |
Will it be safe as main use flags?
I removed -fvisibility-inlines-hidden from my CXXFLAGS (I can confirm at it break things.). Will it be safe to add it with gcc4.1, or will it be the same problems as with gcc3.4? What about -ftracer and gcc4.1?
_________________
"Confirm You are a robot." - the singularity |
|
| Back to top |
|
|
Eduard Munteanu
n00b
Joined: 06 Sep 2006
Posts: 20
Location: Bucuresti, Romania
|
| Posted: Sun Sep 10, 2006 11:07 pm Post subject: |
|
|
moocha, using -momit-leaf-frame-pointer is useless with -fomit-frame-pointer:
| man gcc (4.1.1-r1) wrote: | -momit-leaf-frame-pointer
Don't keep the frame pointer in a register for leaf functions.
This avoids the instructions to save, set up and restore frame
pointers and makes an extra register available in leaf functions.
The option -fomit-frame-pointer removes the frame pointer for all
functions which might make debugging harder. |
Also, -march implies -mtune, so there is no reason to use both. |
|
| Back to top |
|
|
Dominique_71
Veteran
Joined: 17 Aug 2005
Posts: 1877
Location: Switzerland (Romandie)
|
| Posted: Mon Sep 11, 2006 1:10 pm Post subject: |
|
|
I try the flag as in my first messages, but the result was an unusable system. Only xdm and fluxbox was starting, but a lot of other program was just crashing: fluxconf, fluxmenu, gdm, xfce and many more. So I went back to safer flags.
_________________
"Confirm You are a robot." - the singularity |
|
| Back to top |
|
|
rhill
Retired Dev
Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca
|
| Posted: Tue Sep 12, 2006 1:31 am Post subject: |
|
|
-fforce-addr - not a good idea with GCC 4 and x86. x86 already has a horribly limited number of registers, and using more will just increase register pressure, resulting in poorer code. packages that use a lot of hand-made assembly, (eg. ffmpeg, mplayer, transcode) can fail with this flag. same with -frename-registers and -fforce-mem
-ftree-vectorize - still buggy with GCC 4.1 and not improving in 4.2. there's a large number of vectorizer patches that should have gone into 4.2 but were deferred til 4.3 due to lack of proper review. =/ http://tinyurl.com/z79jz
-ftree-loop-linear - ditto, but without the forthcoming patches. don't use this unless you like internal compiler errors. http://tinyurl.com/msfnf
-momit-leaf-frame-pointer - sounds good, but i know there's more than a couple ebuilds that have to filter it to build. (eg. xine-lib, ffmpeg)
_________________
by design, by neglect
for a fact or just for effect |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Tue Sep 12, 2006 4:49 pm Post subject: |
|
|
Hi at all!!!
@dirtyepic I will show you my CFLAGS configuration and LDFLAG (I have a VIA C7 Easter core):
| Code: | CFLAGS="-O2 -march=i686 -mmmx -msse -msse2 -msse3 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--as-needed" |
Does that configuration look good for the system? Fon now I haven't notice any serious problem...
Best regards
Franco Tampieri
_________________
:: [Dr.Dran] Details ::
- Linux User # 286282
- IT FreeLance Consultant
- President of ImoLUG [Imola & Faenza Linux User Group] |
|
| Back to top |
|
|
|
Portage & Programming
