View previous topic :: View next topic |
Author |
Message |
dwilson Tux's lil' helper
Joined: 10 Feb 2003 Posts: 115
|
Posted: Fri Mar 28, 2003 3:14 am Post subject: -fomit-frame-pointer |
|
|
I have read that this optimization should be used. The problem is I haven't build anything on my system with it, and I am wondering if it is ok to just turn it on now and let it slowly permeate through as everything gets recompiled during updates.
Also, I am kind of curious as to what it actually does and if it really improves speed that much. |
|
Back to top |
|
|
Jimbow Guru
Joined: 18 Feb 2003 Posts: 597 Location: Silver City, NM
|
Posted: Fri Mar 28, 2003 3:53 am Post subject: |
|
|
It is fine to turn it on and off whenever you want. The compiler uses up a register as a frame pointer in order to enable stack trace debugging. If you omit the frame pointer, it frees up this register (which makes programs run faster because they don't need to access RAM as much) but it means that you don't get stack traces when programs crash. _________________ After Perl everything else is just assembly language. |
|
Back to top |
|
|
bssteph l33t
Joined: 26 Feb 2003 Posts: 652 Location: Wisconsin
|
Posted: Fri Mar 28, 2003 7:25 am Post subject: |
|
|
It should be perfectly safe to let work its way into your system, but if you wanted to be a bit zealous, you could 'emerge -e world' and rebuild -everything- (assuming you have the time of course)... I did it and never had a problem aside from forgetting about a couple ebuilds that were quirky with my USE flags in make.conf. It's a perfectly safe flag, in my experience.
The rule for fomit-frame-pointer that I've seen is if you're going to be developing and/or testing lots of code, you'll probably want the frame pointer so you can actually trace back any problems... but if you're mainly just general use, it's worth the performance gain to use the flag. |
|
Back to top |
|
|
timbo Apprentice
Joined: 29 Jul 2002 Posts: 231 Location: New Zealand
|
Posted: Fri Mar 28, 2003 9:38 pm Post subject: |
|
|
bssteph
I've built my whole system with this flag cause it was recomended. Now reading the last couple of posts was this a waste of time as I don't care if a program crashes, not interested in finding out why.....
Should I remove this flag from any future emerges?
Regards
Tim
_________________ Linux User: 303160 |
|
Back to top |
|
|
michaelb l33t
Joined: 06 Jun 2002 Posts: 686 Location: Ann Arbor, MI
|
Posted: Fri Mar 28, 2003 9:45 pm Post subject: |
|
|
Timbo,
If you do not want to do any traceback debugging, then you probably want to have the -fomit-frame-pointer flag in your C flags. This potentially breaks debugging, but opens up an extra register for the app at runtime.
Hope that clears it up for you
Michael |
|
Back to top |
|
|
gilesjuk Guru
Joined: 11 Feb 2003 Posts: 412 Location: Staffordshire, UK
|
Posted: Fri Mar 28, 2003 9:57 pm Post subject: |
|
|
The rule is if you like to (and do) submit detailed bug reports then you should not use this flag. Otherwise use it. _________________ ^<^>^<^>^
G. Jones
-=-=-=-=-=- |
|
Back to top |
|
|
masseya Bodhisattva
Joined: 17 Apr 2002 Posts: 2602 Location: Baltimore, MD
|
Posted: Fri Mar 28, 2003 10:47 pm Post subject: |
|
|
gilesjuk wrote: | The rule is if you like to (and do) submit detailed bug reports then you should not use this flag. Otherwise use it. | This could be more like, "If you want to submit a reliable bug report..." _________________ if i never try anything, i never learn anything..
if i never take a risk, i stay where i am.. |
|
Back to top |
|
|
gilesjuk Guru
Joined: 11 Feb 2003 Posts: 412 Location: Staffordshire, UK
|
Posted: Fri Mar 28, 2003 11:01 pm Post subject: |
|
|
masseya wrote: | This could be more like, "If you want to submit a reliable bug report..." |
It's still possible to submit a reliable report, it's just that you won't be able to submit a backtrace and pinpoint the problem. _________________ ^<^>^<^>^
G. Jones
-=-=-=-=-=- |
|
Back to top |
|
|
masseya Bodhisattva
Joined: 17 Apr 2002 Posts: 2602 Location: Baltimore, MD
|
Posted: Fri Mar 28, 2003 11:08 pm Post subject: |
|
|
Yeah, kinda. However, the devs don't use -fomit-frame-pointer, so if you submit a bug report and you expect them to be able to reproduce the bug then you're guaranteed (to an extent) that your bug report will be unreliable in the case that the problem is with -fomit-frame-pointer. In general, you should try testing your setup with a set of minimal compilation flags before submitting a bug report. This helps devs a lot, but I can certainly see how it's not always possible. _________________ if i never try anything, i never learn anything..
if i never take a risk, i stay where i am.. |
|
Back to top |
|
|
GojiraST n00b
Joined: 14 Mar 2003 Posts: 41 Location: Florida
|
Posted: Sat Mar 29, 2003 2:16 am Post subject: |
|
|
Well... as a person who does software QA for a living, we usually test "retail" builds, that is, the binaries the customers will get. Granted most of what I test is Windows based (unfortunately), but most of the time only the developers use "debug" builds. One reason for this (and I can't speak to this being true in the case of this particular pointer), is that we have had bugs in the past that don't show up with the debug code in place, but do for the binaries that ship. If it becomes necessary, it's a simple matter to put the debug binaries in place.
I would think that if someone wanted to submit a bug, it should be relatively simple for them to re-emerge with the fomit flag turned off, if that's useful in tracking the bug.
And yes, I'm aware that the debug code that's placed in developmental builds is a mite different from the register reserved for traces in this case, but it's a similar concept. If most end users are likely to build with that flag in place for performance reasons, most non-developer testing should likely be done that way. I know I'm willing to set whatever flags and compile however is requested by the developer in the course of researching the bug, but I'm not usually going to do that before submitting it...
As a side note, I have learned more about how Linux systems work in the time I've been using Gentoo than in my previous 5+ years of Linux experience.
I taught a small class last year to co-workers on Linux installation and use based solely on the Gentoo Install and Desktop config docs.
As I get more proficient and confident, I'll do everything I can to contribute both here on the forums, and through bug-submission/research, and one day development |
|
Back to top |
|
|
masseya Bodhisattva
Joined: 17 Apr 2002 Posts: 2602 Location: Baltimore, MD
|
Posted: Sat Mar 29, 2003 2:23 pm Post subject: |
|
|
It would be nice if the Gentoo team was large enough to have a QA department that could be soley dedicated to testing the ebuilds with as many different flag combinations as possible. However, that's probably a little bit out of their capabilities for the foreseeable future. As you said, it shouldn't be too bad to just try the ebuild with a set of reduced compiler optimizations before submitting a bug report. _________________ if i never try anything, i never learn anything..
if i never take a risk, i stay where i am.. |
|
Back to top |
|
|
Narada Guru
Joined: 12 Dec 2002 Posts: 300 Location: London, UK
|
Posted: Sat Mar 29, 2003 4:04 pm Post subject: |
|
|
CFLAGS can be changed at anytime and will then become applicable to all future emerge compilations. The performance of -fomit-frame-pointer has received a good consensus from all who use it and is generally a good idea. If CFLAG changes are considerable and you wish to recompile all packages with the new CFLAGS use command below. Beware that this is time consuming and will generate many configuration files to sort through.
_________________ http://dhruba.name/ |
|
Back to top |
|
|
GojiraST n00b
Joined: 14 Mar 2003 Posts: 41 Location: Florida
|
Posted: Sun Mar 30, 2003 2:22 am Post subject: |
|
|
yup. I won't submit one without baselining it against a debug compile (I've already inserted a commented out set of CFLAG, CXFLAG, etc lines in my make.conf). I'll probably post here to get more feedback while I'm researching/before I debug. I won't file on Bugzilla without full debug. Thanks for reminding me that this isn't the same as the projects I work on for money |
|
Back to top |
|
|
pblinux n00b
Joined: 07 Jan 2006 Posts: 17
|
Posted: Mon Feb 06, 2006 7:48 am Post subject: |
|
|
At the risk of waking a long-dead thread, I have a question:
Code: | -fomit-frame-pointer | seems to be considered "safe" around here, but I'm wondering if it has any connection to the following wine error (Civ4 under wine0.9.7):
Code: | err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception. |
I'm very new to linux, so I don't know what I'm talking about, but it seems the terminology is quite similar. Will nixing -fomit-frame-pointer and reemerging world have a chance of clearing this hurdle, or is that a waste of time because they are unrelated? |
|
Back to top |
|
|
nixnut Bodhisattva
Joined: 09 Apr 2004 Posts: 10974 Location: the dutch mountains
|
Posted: Mon Feb 06, 2006 5:50 pm Post subject: |
|
|
Moved from Installing Gentoo to Portage & Programming.
Not an installation support question, so moved here. _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
Back to top |
|
|
predatorfreak l33t
Joined: 13 Jan 2005 Posts: 708 Location: USA, Michigan.
|
Posted: Mon Mar 06, 2006 7:57 pm Post subject: |
|
|
Even though I'm not a regular C developer, there is near no way I can recommend -fomit-frame-pointer because it can increase binary size by a good margine and really I can't notice the performance difference with or without it. I don't think the I/O bashing you go through with large applications is worth the one extra register gain from using the flag. _________________ System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
Back to top |
|
|
nmbrthry Tux's lil' helper
Joined: 21 Jun 2005 Posts: 80 Location: Urbana-Champaign, IL
|
Posted: Tue Mar 07, 2006 3:30 am Post subject: |
|
|
predatorfreak wrote: | Even though I'm not a regular C developer, there is near no way I can recommend -fomit-frame-pointer because it can increase binary size by a good margine and really I can't notice the performance difference with or without it. I don't think the I/O bashing you go through with large applications is worth the one extra register gain from using the flag. |
Can you explain this? I don't see how -fomit-frame-pointer would increase binary size or lead to I/O bashing. |
|
Back to top |
|
|
predatorfreak l33t
Joined: 13 Jan 2005 Posts: 708 Location: USA, Michigan.
|
Posted: Tue Mar 07, 2006 10:35 pm Post subject: |
|
|
nmbrthry wrote: | predatorfreak wrote: | Even though I'm not a regular C developer, there is near no way I can recommend -fomit-frame-pointer because it can increase binary size by a good margine and really I can't notice the performance difference with or without it. I don't think the I/O bashing you go through with large applications is worth the one extra register gain from using the flag. |
Can you explain this? I don't see how -fomit-frame-pointer would increase binary size or lead to I/O bashing. |
I shouldn't really NEED to explain it, just see for yourself. Take any app that you don't mind recompiling, even a very small application like rxvt-unicode will show a size increase off the bat by using -fomit-frame-pointer.
The I/O bashing is less of a problem with small applications, like rxvt-unicode or other small applications. It becomes a concern with applications like firefox, which are very large and must load a large number of libraries at their start. The overhead produced by having larger files means that it takes longer for each file to be referenced from the disk and to load what is required into memory. That overhead with something like rxvt-unicode isn't even noticable, but with applications such as firefox, it's noticable. _________________ System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
Back to top |
|
|
nmbrthry Tux's lil' helper
Joined: 21 Jun 2005 Posts: 80 Location: Urbana-Champaign, IL
|
Posted: Wed Mar 08, 2006 3:34 am Post subject: |
|
|
predatorfreak wrote: |
I shouldn't really NEED to explain it, just see for yourself. Take any app that you don't mind recompiling, even a very small application like rxvt-unicode will show a size increase off the bat by using -fomit-frame-pointer.
|
Results:
xterm-208
with -fomit-frame-pointer: 271474
without: 269618
0.6884% increase
vim-6.4
with: 1403155
without: 1394963
0.5873% increase
gtk+-2.8.13
with: 3734829
without: 3693604
1.1161% increase
The only other CFLAG listed was -O2 in each case.
Average increase: 0.7973% (too small of a sample to be useful, of course)
If we take a 10MB executable/library, we might see a 100kB increase if we're unlucky. Most harddisks can read an extra 100kB pretty quickly.
So back to my original question... why does omitting the frame pointer lead to larger code? |
|
Back to top |
|
|
predatorfreak l33t
Joined: 13 Jan 2005 Posts: 708 Location: USA, Michigan.
|
Posted: Wed Mar 08, 2006 5:37 am Post subject: |
|
|
nmbrthry wrote: | predatorfreak wrote: |
I shouldn't really NEED to explain it, just see for yourself. Take any app that you don't mind recompiling, even a very small application like rxvt-unicode will show a size increase off the bat by using -fomit-frame-pointer.
|
Results:
xterm-208
with -fomit-frame-pointer: 271474
without: 269618
0.6884% increase
vim-6.4
with: 1403155
without: 1394963
0.5873% increase
gtk+-2.8.13
with: 3734829
without: 3693604
1.1161% increase
The only other CFLAG listed was -O2 in each case.
Average increase: 0.7973% (too small of a sample to be useful, of course)
If we take a 10MB executable/library, we might see a 100kB increase if we're unlucky. Most harddisks can read an extra 100kB pretty quickly.
So back to my original question... why does omitting the frame pointer lead to larger code? |
Like I said, I don't really know. The increase is enough for me to take notice (an increase of 2K or something is nothing to me for a good cause, but an increase of 2k and breaking debugging isn't worth it to me). Maybe you should ask the GCC developers? I really can't think of ANY reason it should increase the code size. _________________ System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
Back to top |
|
|
chtephan Apprentice
Joined: 03 Feb 2004 Posts: 266 Location: Offenburg, Germany
|
Posted: Wed Mar 08, 2006 8:48 am Post subject: |
|
|
Perhaps it has something to do with the fact the the frame pointer operations are one-byte commands while most basic register commands are larger on i386 (which doesn't mean they're slower). Comparing the assembler core side by side might give an explanation. |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Wed Mar 08, 2006 1:31 pm Post subject: |
|
|
IIRC to free the frame pointer, you need to add a bit of code - for every function doing this trick. |
|
Back to top |
|
|
predatorfreak l33t
Joined: 13 Jan 2005 Posts: 708 Location: USA, Michigan.
|
Posted: Thu Mar 09, 2006 12:13 am Post subject: |
|
|
PrakashP wrote: | IIRC to free the frame pointer, you need to add a bit of code - for every function doing this trick. |
Then OMITTING the frame pointer SHOULD actually decrease the code size. But it does the opposite. Also, the increase seems to be WORSE with C++ applications, e.g rxvt-unicode goes up from 192K to 220K without frame pointers.
chtephan wrote: | Perhaps it has something to do with the fact the the frame pointer operations are one-byte commands while most basic register commands are larger on i386 (which doesn't mean they're slower). Comparing the assembler core side by side might give an explanation. |
I'm taking a random guess, but maybe because it gives it an extra register to work with, it increases code size by increasing register usage? (I'm probably dead wrong) _________________ System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
Back to top |
|
|
Seppel Tux's lil' helper
Joined: 10 Nov 2002 Posts: 113
|
Posted: Thu Mar 09, 2006 3:07 am Post subject: |
|
|
predatorfreak wrote: | Like I said, I don't really know. The increase is enough for me to take notice (an increase of 2K or something is nothing to me for a good cause, but an increase of 2k and breaking debugging isn't worth it to me). Maybe you should ask the GCC developers? I really can't think of ANY reason it should increase the code size. |
This has to do with x86. Without -fomit-frame-pointer parameters and local variables are accessed via the frame pointer %ebp. With frame-pointer-ommision %ebp is used for whatever suits and parameters/local vars are accessed via the stack pointer %esp. Now, for some oddity I'll leave out, memory accesses via %esp are one byte longer than via %ebp:
Code: |
8b442404 mov eax, [esp+4] // copy memory cell esp+4 into eax
8b4504 mov eax, [ebp+4] // copy memory cell ebp+4 into eax
|
The first opcode need 4 bytes, while the second needs only 3 bytes. |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Thu Mar 09, 2006 8:15 am Post subject: |
|
|
predatorfreak wrote: | PrakashP wrote: | IIRC to free the frame pointer, you need to add a bit of code - for every function doing this trick. |
Then OMITTING the frame pointer SHOULD actually decrease the code size. But it does the opposite. Also, the increase seems to be WORSE with C++ applications, e.g rxvt-unicode goes up from 192K to 220K without frame pointers.
|
Learn a bit of assembler then you'll understand that this is not a contradiction. |
|
Back to top |
|
|
|