Ommiting frame pointer

[Brian]

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.

[Richard Tobin]

In article <sl************ *******@nospam. invalid>,
Brian <tr**@nospam.co mwrote:

>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

[Ben Pfaff]

Brian <tr**@nospam.co mwrites:

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.progr ammer 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

[llothar]

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.

[Ian Collins]

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.

[Boudewijn Dijkstra]

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/

[Stephen Sprunk]

"llothar" <ll*****@web.de wrote in message
news:8e******** *************** ***********@i12 g2000prf.google groups.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

[Brian]

>>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

[Richard Tobin]

In article <sl************ *******@nospam. invalid>,
Brian <tr**@nospam.co mwrote:

>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

[Stephen Sprunk]

"Brian" <tr**@nospam.co mwrote in message
news:sl******** ***********@nos pam.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