473,322 Members | 1,352 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Ommiting frame pointer

Hello -

I have been told that for extra efficiency we should always compile
code with frame pointer ommited (-fomit-frame-pointer), also -pipe.

What is the reason for this? Why does it make a better executable? Are
there situations where it doesn't work or isn't the best thing to do?

Also I don't understand why not always make Position Independent Code
(-fPIC)?

Thanks.

Dec 12 '07 #1
14 1819
In article <sl*******************@nospam.invalid>,
Brian <tr**@nospam.comwrote:
>I have been told that for extra efficiency we should always compile
code with frame pointer ommited (-fomit-frame-pointer)
Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors). Using one can make debugging easier,
though I think gdb can do most things without one.
also -pipe.
This gcc option just uses pipes between compiler stages instead of
temporary files. It might speed up compilation a little but probably
not a lot on current systems.
>Also I don't understand why not always make Position Independent Code
(-fPIC)?
Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.

You may get more detailed or accurate answers in a gcc-specific group.

-- Richard
--
:wq
Dec 13 '07 #2
Brian <tr**@nospam.comwrites:
I have been told that for extra efficiency we should always compile
code with frame pointer ommited (-fomit-frame-pointer), also -pipe.

What is the reason for this? Why does it make a better executable? Are
there situations where it doesn't work or isn't the best thing to do?

Also I don't understand why not always make Position Independent Code
(-fPIC)?
comp.unix.programmer or gnu.gcc.help would be better places to
ask these questions, because they deal with matters that are not
defined by standard C.
--
Ben Pfaff
http://benpfaff.org
Dec 13 '07 #3
Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors).
I haven't seen any influence on modern x86 CPU's anymore. The number
of registers
does simply not matter with the gcc code generator at the moment (even
amd64
has no significant performance improvement).
Also I don't understand why not always make Position Independent Code
(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
Only on x86. amd64 has Instruction pointer relative operations so
there is
no extra indirection.
Dec 13 '07 #4
llothar wrote:
>Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors).

I haven't seen any influence on modern x86 CPU's anymore. The number
of registers
does simply not matter with the gcc code generator at the moment (even
amd64
has no significant performance improvement).
It may not with gcc, but other compilers do gain when omitting the frame
pointer on AMD64.

--
Ian Collins.
Dec 13 '07 #5
Op Thu, 13 Dec 2007 10:38:22 +0100 schreef llothar <ll*****@web.de>:
>Also I don't understand why not always make Position Independent Code
(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
For the x86-family,
Only on x86. amd64 has Instruction pointer relative operations so
there is no extra indirection.
There are dozens more architectures than x86 and amd64.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Dec 13 '07 #6
"llothar" <ll*****@web.dewrote in message
news:8e**********************************@i12g2000 prf.googlegroups.com...
>Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors).

I haven't seen any influence on modern x86 CPU's anymore. The
number of registers does simply not matter with the gcc code
generator at the moment (even amd64 has no significant
performance improvement).
I've seen programs where the extra register(s) made a measurable (sometimes
huge) difference and others where it had no effect at all. It all depends
on the particular code being compiled, other optimizations enabled, etc.
>Also I don't understand why not always make Position Independent
Code (-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.

Only on x86. amd64 has Instruction pointer relative operations so
there is no extra indirection.
I've read that some architectures have no performance penalty for PIC, but
x86 and amd64 definitely do not fall in that group. Amd64's RIP-relative
addressing reduces the penalty but does not eliminate it.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Dec 13 '07 #7
>>I have been told that for extra efficiency we should always compile
>>code with frame pointer ommited (-fomit-frame-pointer)

Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors). Using one can make debugging easier,
though I think gdb can do most things without one.
Wouldn't it be better then if the frame pointer was ommited by default
unless debugging (-g) is switched on?
>also -pipe.

This gcc option just uses pipes between compiler stages instead of
temporary files. It might speed up compilation a little but probably
not a lot on current systems.
So why isn't this enabled by default?
>>Also I don't understand why not always make Position Independent Code
(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
Isn't it good to be able to relocate all code, not just library code?

Best

Brian

Dec 14 '07 #8
In article <sl*******************@nospam.invalid>,
Brian <tr**@nospam.comwrote:
>Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
>Isn't it good to be able to relocate all code, not just library code?
Why? Who needs to relocate code in complete programs?

The code in compiled-but-not-linked files (.o files in unix) is
relocatable in the sense that it doesn't yet have the addresses filled
in, but that's a quite separate issue: when it's linked, a new version
is made with the addresses filled in. The code in shared libraries
needs to be runnable at different addresses without copying it (so it
can be shared).

-- Richard
--
:wq
Dec 14 '07 #9
"Brian" <tr**@nospam.comwrote in message
news:sl*******************@nospam.invalid...
>>>I have been told that for extra efficiency we should always compile
code with frame pointer ommited (-fomit-frame-pointer)

Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors). Using one can make debugging easier,
though I think gdb can do most things without one.

Wouldn't it be better then if the frame pointer was ommited by default
unless debugging (-g) is switched on?
Some debugging can be done without symbols, and it's easier with a frame
pointer.
>>also -pipe.

This gcc option just uses pipes between compiler stages instead of
temporary files. It might speed up compilation a little but probably
not a lot on current systems.

So why isn't this enabled by default?
Because a pipe means multiple compiler stages would be in memory and
consuming CPU at the same time. That may be fine for some systems, but it
isn't for others.
>>>Also I don't understand why not always make Position Independent Code
(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.

Isn't it good to be able to relocate all code, not just library code?
Non-library code is relocated at link time; it doesn't need to be
position-independent (or relocated) at runtime.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Dec 14 '07 #10
On 14 Dec 2007 at 18:22, Stephen Sprunk wrote:
"Brian" <tr**@nospam.comwrote in message
news:sl*******************@nospam.invalid...
>>>>I have been told that for extra efficiency we should always compile
code with frame pointer ommited (-fomit-frame-pointer)

Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors). Using one can make debugging easier,
though I think gdb can do most things without one.

Wouldn't it be better then if the frame pointer was ommited by default
unless debugging (-g) is switched on?

Some debugging can be done without symbols, and it's easier with a frame
pointer.
But if you are planning to debug, why wouldn't you include symbols (-g)?
>>>also -pipe.

This gcc option just uses pipes between compiler stages instead of
temporary files. It might speed up compilation a little but probably
not a lot on current systems.

So why isn't this enabled by default?

Because a pipe means multiple compiler stages would be in memory and
consuming CPU at the same time. That may be fine for some systems, but it
isn't for others.
OK, but nowadays any computer will have huge CPU and RAM resources, so
why not make -pipe the default and let people turn it off if they're
compiling on a stone-age machine?
>>>>Also I don't understand why not always make Position Independent Code
(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.

Isn't it good to be able to relocate all code, not just library code?

Non-library code is relocated at link time; it doesn't need to be
position-independent (or relocated) at runtime.
But if it doesn't cost anything to have the extra flexibility, then why
not?

Best

Brian

Dec 14 '07 #11
Richard Tobin wrote:
Brian <tr**@nospam.comwrote:
>>Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
>Isn't it good to be able to relocate all code, not just library code?

Why? Who needs to relocate code in complete programs?

The code in compiled-but-not-linked files (.o files in unix) is
relocatable in the sense that it doesn't yet have the addresses filled
in, but that's a quite separate issue: when it's linked, a new version
is made with the addresses filled in. The code in shared libraries
needs to be runnable at different addresses without copying it (so it
can be shared).
The voice of someone who has never seen machines without relocation
registers. The innocence of youth.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Dec 14 '07 #12
"Brian" <tr**@nospam.comwrote in message
news:sl*******************@nospam.invalid...
On 14 Dec 2007 at 18:22, Stephen Sprunk wrote:
>"Brian" <tr**@nospam.comwrote in message
news:sl*******************@nospam.invalid...
>>>>>I have been told that for extra efficiency we should always compile
>code with frame pointer ommited (-fomit-frame-pointer)

Not using a frame pointer makes an extra register available for other
uses, which speeds things up on processors with few registers (in
particular, on x86 processors). Using one can make debugging easier,
though I think gdb can do most things without one.

Wouldn't it be better then if the frame pointer was ommited by default
unless debugging (-g) is switched on?

Some debugging can be done without symbols, and it's easier with a frame
pointer.

But if you are planning to debug, why wouldn't you include symbols (-g)?
I'm usually not _planning_ to debug. Bugs are things that take one by
surprise, because if they weren't, one would have already fixed the problem.
When we ship products to customers, they do not contain symbols; if the code
crashes, we have to debug the code without them -- or dig up the separate
symbol files we don't ship.

Of course, when adding a new function or doing unit tests, all the
appropriate flags are set to make debugging as easy as possible, but some
always manage to hide until customers get their hands on the "finished"
product.
>>>>also -pipe.

This gcc option just uses pipes between compiler stages instead of
temporary files. It might speed up compilation a little but probably
not a lot on current systems.

So why isn't this enabled by default?

Because a pipe means multiple compiler stages would be in memory and
consuming CPU at the same time. That may be fine for some systems, but
it
isn't for others.

OK, but nowadays any computer will have huge CPU and RAM resources, so
why not make -pipe the default and let people turn it off if they're
compiling on a stone-age machine?
*shrug* Take that up with the GCC folks.
>>>>>Also I don't understand why not always make Position Independent Code
>(-fPIC)?

Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.

Isn't it good to be able to relocate all code, not just library code?

Non-library code is relocated at link time; it doesn't need to be
position-independent (or relocated) at runtime.

But if it doesn't cost anything to have the extra flexibility, then why
not?
On most systems I'm familiar with, PIC code is larger and slower. If you
don't need to suffer that penalty, you don't turn it on.

On the systems where there is no penalty for PIC code, it's on by default
(IIRC).

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Dec 15 '07 #13
On 14 Dec, 18:50, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <slrnfm5g26.hn7.nos...@nospam.invalid>,
Brian <t...@nospam.comwrote:
Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
Isn't it good to be able to relocate all code, not just library code?

Why? Who needs to relocate code in complete programs?
machines with pageing but without virtual memory.
Old Macs needed to relocate code on-the-fly.
Didn't Crays not have virtual memory?
The code in compiled-but-not-linked files (.o files in unix) is
relocatable in the sense that it doesn't yet have the addresses filled
in, but that's a quite separate issue: when it's linked, a new version
is made with the addresses filled in. The code in shared libraries
needs to be runnable at different addresses without copying it (so it
can be shared).

--
Nick Keighley
Dec 17 '07 #14
In article <fa**********************************@b1g2000pra.g ooglegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:
>Position independent code is likely to be somewhat slower on most
systems, just because of extra indirections. It's needed for shared
libraries.
>Isn't it good to be able to relocate all code, not just library code?
>Why? Who needs to relocate code in complete programs?
>machines with pageing but without virtual memory.
Old Macs needed to relocate code on-the-fly.
Didn't Crays not have virtual memory?
In other words, almost nobody. Unless you have peculiar requirements,
there's no advantage to position independent code outside libraries.

-- Richard
--
:wq
Dec 17 '07 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Phil | last post by:
Supposedly, the code below should assign the correct value to the 'url' variable. But all I get is a blank 'main' Frame with apparently nowhere to go when I click on the link in the 'menu'...
5
by: Tim Streater | last post by:
I have this arrangement of frames: <html><head><script type="text/javascript"></script></head> <frameset rows="100,*"> <frameset cols="135,*,165"> <frame name="logo" src="some.html"...
3
by: asm | last post by:
Hello all, I need your help on this problem. I wrote a little program as follows. (BTW, I worked on a new dell latitude, runing Linux kernel 2.4.19, i686). Program was compiled with gcc 3.2 ...
4
by: anonymous | last post by:
Thanks your reply. The article I read is from www.hakin9.org/en/attachments/stackoverflow_en.pdf. And you're right. I don't know it very clearly. And that's why I want to understand it; for it's...
0
by: Søren M. Olesen | last post by:
How do I manipulate a control in one frame from another frame ?? I've tried something like: Class1 TextBox.Text="Text1" Session("TextBox")=TextBox1 Class2
4
by: AndrewV | last post by:
I have an html page that has 2 frames ("input" and "result"). In the "input" frame, there is a text box and a button. User enters an id in the text box, then click on the button. In the click...
5
by: Martin Chen | last post by:
I have a frame set (as per MS FrontPage 2000). It has a contents and a main frame. The contents frame has a menu bar written with with javascript (in the context of a table). In IE6.1 everything...
2
by: bekz | last post by:
Hi All, I have written exploits for binaries with fixed stack frame pointer. But now a days most of the compliers generates instrutions with random stack frame pointer. And with injecting...
4
by: code break | last post by:
Hi all, What is the difference between stack pointer and frame pointer ? Any suggestions are welcome ,,,
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.