By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,305 Members | 1,588 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,305 IT Pros & Developers. It's quick & easy.

inline question

P: n/a
Hi,
As inline is not mandetory, it depends on compiler to inline certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but is
it free to choose a non inline function to inline it?
I have some simple one line get function, and index operators which I
want to get inlined. But due to some problem (like I have some circular
dependency, thus use forward declaration, and hence not possible to
have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining? If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.
Those get functions return certain kind of container , which in turns
a class use to return a begin & end iterator for the container. ( i.e a
view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).

Sep 27 '06 #1
Share this Question
Share on Google+
25 Replies


P: n/a

toton ha scritto:
Hi,
As inline is not mandetory, it depends on compiler to inline certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but is
it free to choose a non inline function to inline it?
I have some simple one line get function, and index operators which I
want to get inlined. But due to some problem (like I have some circular
dependency, thus use forward declaration, and hence not possible to
have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining? If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.
Those get functions return certain kind of container , which in turns
a class use to return a begin & end iterator for the container. ( i.e a
view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).
I think that most compilers choose if "inline" a function by itself,
they don't care much about the inline keyword. They often don't
"inline" a function that is declared inline or they do so even if you
didn't declare it inline.

Sep 27 '06 #2

P: n/a
Paolo wrote:
I think that most compilers choose if "inline" a function by itself,
they don't care much about the inline keyword. They often don't
"inline" a function that is declared inline or they do so even if you
didn't declare it inline.
The rule here is called "as if".

The C++ Standard reputedly describes a C++ compiler in terms of creating
specific kinds of opcodes. But compilers are free to create any kind of
alternate opcodes so long as the results perform "as if" the compiler had
created the specified opcodes.

So a compiler might inline functions in ways that optimize the calling code,
regardless which called functions are declared inline.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 27 '06 #3

P: n/a
toton wrote:
Hi,
As inline is not mandetory, it depends on compiler to inline
certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but
is
it free to choose a non inline function to inline it?
Yes. The compiler can do whatever it wants, as long as the visible
effect is the same. How would you detect whether a function is inlined
or pot?
I have some simple one line get function, and index operators which
I
want to get inlined. But due to some problem (like I have some
circular dependency, thus use forward declaration, and hence not
possible to have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining?
That doesn't stop some compilers from inlining anyway.
If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.
A function call will cost some more. Does it matter?

If a one line getter takes twice as long, will anyone notice?
Those get functions return certain kind of container , which in
turns
a class use to return a begin & end iterator for the container. (
i.e
a view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).
Here the answer is of course the boring "It depends". :-)

There is no general answer for a kind of container with some iterator,
where some functions might get inlined (or not). To get the true
result, you have to try it out and measure if it is fast enough. Most
often it is.
Bo Persson
Sep 27 '06 #4

P: n/a
"toton" <ab*******@gmail.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...
: Hi,
: As inline is not mandetory, it depends on compiler to inline certain
: function (or using switch like fior GCC), my question is there any
: scope for inlining when it is not declared as inline function?
: i.e compiler may choose not to inline certain inline function, but is
: it free to choose a non inline function to inline it?
Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.
Some current compilers will automatically inline some functions
in optimized builds - or decide to refuse inlining some functions
(e.g. when compiling in "optimize for size" mode).

: Secondly, If i build a library with the getter function in the cpp
: file, rather than header, (and so it is not inlined) , does it mean
: that the scope for optimization is lost for inlining?
In most cases yes, probably, although not necessarily.
Several platforms today implement linker-time global program
optimizations, and might inline such functions as well.
hth --Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <http://www.brainbench.com

Sep 27 '06 #5

P: n/a

Ivan Vecerina wrote:
"toton" <ab*******@gmail.comwrote in message
news:11**********************@e3g2000cwe.googlegro ups.com...
: Hi,
: As inline is not mandetory, it depends on compiler to inline certain
: function (or using switch like fior GCC), my question is there any
: scope for inlining when it is not declared as inline function?
: i.e compiler may choose not to inline certain inline function, but is
: it free to choose a non inline function to inline it?
Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.
So a bright future! I wish a quick death to keywords like register,
auto and inline. But at the same time it is better to have attributes
to guide compiler. @inline can be an attribute to guide compiler to
inline certain code. Because it is almost always true that human being
knows more about the program than compiler do. Thus a loop unrolling
behaviour may be needed for some particular loop which runs too
frequent (may be even a big loop), while a small loop which runs rarely
in runtime may not need that kind of attention! Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it :)
Some current compilers will automatically inline some functions
in optimized builds - or decide to refuse inlining some functions
(e.g. when compiling in "optimize for size" mode).

: Secondly, If i build a library with the getter function in the cpp
: file, rather than header, (and so it is not inlined) , does it mean
: that the scope for optimization is lost for inlining?
In most cases yes, probably, although not necessarily.
Several platforms today implement linker-time global program
optimizations, and might inline such functions as well.
hth --Ivan
--
The group is really nice!
Thanks for the reply.
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <http://www.brainbench.com
Sep 27 '06 #6

P: n/a

toton wrote:
[snip]
Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it :)
This is done today already.

Sep 27 '06 #7

P: n/a
toton wrote:
I have some simple one line get function, and index operators
which I want to get inlined. But due to some problem (like I have
some circular dependency, thus use forward declaration, and hence
not possible to have some get function implemented in header).
If you use a macro instead of a function, then it will definitely get
inlined. Just be careful.

BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.

Steve
Sep 27 '06 #8

P: n/a
Steve Pope wrote:
BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.
There is no compiling difference between these two foo() functions:

struct A { void foo() {} };
struct B { inline void foo() {} };

Both allow foo()'s body to appear in more than one translation unit. Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 27 '06 #9

P: n/a
"Ivan Vecerina" <_INVALID_use_webform_@_ivan.vecerina.com_writes :
Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.
inline is part of the ODR. I can't see how inline can be made
redundant without changing it.

Regards,

Jens
Sep 27 '06 #10

P: n/a
Phlip <ph******@yahoo.comwrote:
>Steve Pope wrote:
>BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.
>There is no compiling difference between these two foo() functions:
struct A { void foo() {} };
struct B { inline void foo() {} };
>Both allow foo()'s body to appear in more than one translation unit. Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.
Why do you say that the first form offers a "strong suggestion"
to inline the opcode?

Steve
Sep 27 '06 #11

P: n/a
Jens Theisen wrote:
inline is part of the ODR. I can't see how inline can be made
redundant without changing it.
'Register' and 'auto' no longer have a meaning. 'inline' does.

My hope is the C languages in general will graduate from their broken linker
model, where we must define everything twice just so an O file doesn't need
to contain real linking information.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 27 '06 #12

P: n/a
Phlip <ph******@yahoo.comwrote:
>Jens Theisen wrote:
>inline is part of the ODR. I can't see how inline can be made
redundant without changing it.
>'Register' and 'auto' no longer have a meaning. 'inline' does.
>My hope is the C languages in general will graduate from their broken linker
model, where we must define everything twice just so an O file doesn't need
to contain real linking information.
I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.

This was not so bad in C, since you would typically declare them all at
the beginning of the function's block, and the compiler would place
them in registers until it ran out. In C++, with vairables declared
willy-nilly throughout the function, the register keyword is more
useful.

Steve
Sep 27 '06 #13

P: n/a
Steve Pope wrote:
>>There is no compiling difference between these two foo() functions:
> struct A { void foo() {} };
struct B { inline void foo() {} };
>>Both allow foo()'s body to appear in more than one translation unit.
Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.

Why do you say that the first form offers a "strong suggestion"
to inline the opcode?
[Because C languages don't store very much data in a linker, so] at compile
time, a compiler sees many functions in each translation unit. It must
decide which to inline, and must re-decide once per translation unit. The
functions with external linkage, it _generally_ should not inline, because
the external callers must find an address to jump to, and expressing the
function twice (once inline and again out-of-line) is _generally_
inefficient. (The compiler might still do it.) And the compiler _generally_
cannot share optimization data between translation units. (Sometimes it can;
historically it couldn't!)

Both A::foo and B::foo don't have external linkage. Both can appear in more
than one translation unit, if their definitions are exactly the same. (And
linkers generally don't check that they are the same, at link time!)

Hence, both A::foo and B::foo have told the compiler all it is capable of
knowing about whether to inline either method, and both tell it the same
amount of information. No external linkage == yes the odds are low that
someone will take the address of either foo, or generally do something
requiring the compiler to express an out-of-line version of it.

In general, the idea that 'inline' forms any kind of command, to a compiler,
to inline a function, is a big myth.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 27 '06 #14

P: n/a
Steve Pope wrote:
I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.
Are you directly aware of any compiler that actually obeys that keyword in
any way?

I have not studied this topic, yet I grew the suspicion that they all
discard it these days.

Also, registering the variable that's used "most frequently" might actually
not improve performance!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 27 '06 #15

P: n/a
>>>There is no compiling difference between these two foo() functions:
>>
>> struct A { void foo() {} };
struct B { inline void foo() {} };
And I suspect all this analysis is simply orthogonal to the Standard's
commandment that A::foo is treated as if decorated with an 'inline', because
it is fully defined inside A's definition...
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Sep 28 '06 #16

P: n/a
Phlip <ph******@yahoo.comwrote:
>Steve Pope wrote:
>>>There is no compiling difference between these two foo() functions:
>> struct A { void foo() {} };
struct B { inline void foo() {} };
>>>Both allow foo()'s body to appear in more than one translation unit.
Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.
>Why do you say that the first form offers a "strong suggestion"
to inline the opcode?
>[Because C languages don't store very much data in a linker, so] at compile
time, a compiler sees many functions in each translation unit. It must
decide which to inline, and must re-decide once per translation unit. The
functions with external linkage, it _generally_ should not inline, because
the external callers must find an address to jump to, and expressing the
function twice (once inline and again out-of-line) is _generally_
inefficient. (The compiler might still do it.)
Good explanation. I'll agree that, without lots of monkey tricks
in the linker, functions defined in one translation unit are not
going to be easily inlined when called from another translation unit.

On the other hand, just to nitpick, if the function definition
and the caller *are* in the same translation unit, whether that
function is defined within a class declaration, or outside of
any class declaration, does not affect the ease with which it
could be inlined.

Steve
Sep 28 '06 #17

P: n/a
Phlip <ph******@yahoo.comwrote:
>Steve Pope wrote:
>I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.
Are you directly aware of any compiler that actually obeys
that keyword in any way?
Yes, certainly with gcc (as of a few years ago, and don't ask
me which version) I have obtained speedups by using "register"
even at -O4 or -O5. Particularly when register is applied to
a pointer that subsequently has the ++ or -- operator applied.

Steve
Sep 28 '06 #18

P: n/a

peter koch wrote:
toton wrote:
[snip]
Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it :)
This is done today already.
Which compiler do it for C++? I only know IBM Java VM cache the Jitted
code from first run of the Java program, for subsiquent runs. Not aware
of any other compiler (C++ or any other language), which ask user or
programmer for a few "typical run" of the program and optimize the
code. This is something like optimizing the code statically, before
actual run, based on standard run for specific processor architecture.
Interested to hear about such AOT compilers or some reference to them.
:)

Sep 28 '06 #19

P: n/a

Steve Pope wrote:
toton wrote:
I have some simple one line get function, and index operators
which I want to get inlined. But due to some problem (like I have
some circular dependency, thus use forward declaration, and hence
not possible to have some get function implemented in header).

If you use a macro instead of a function, then it will definitely get
inlined. Just be careful.
Macros are evil. I will never use them except some very simple cases,
even when I am very carefull.
http://www.parashift.com/c++-faq-lit...s.html#faq-9.5
BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.
I hadn't said that. What I had said is that inlined functions need to
be in header (not translation unit) , may be at the place of
declaration, or may be seperately after declaration. If the whole
header file has forward declaration of cetrain class, due to circular
dependency, One can not write inline function which use the definition.
Steve
Sep 28 '06 #20

P: n/a
toton <ab*******@gmail.comwrote:
>Steve Pope wrote:
>toton wrote:
>>I have some simple one line get function, and index operators
which I want to get inlined. But due to some problem (like I have
some circular dependency, thus use forward declaration, and hence
not possible to have some get function implemented in header).
>If you use a macro instead of a function, then it will definitely get
inlined. Just be careful.
>Macros are evil. I will never use them except some very simple cases,
even when I am very careful.
Agreed. (But you did say you wanted some functions/operators inlined,
and this is one approach...)
>BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.
>I hadn't said that. What I had said is that inlined functions need to
be in header (not translation unit) , may be at the place of
declaration, or may be seperately after declaration. If the whole
header file has forward declaration of cetrain class, due to circular
dependency, One can not write inline function which use the definition.
Thanks, that makes sense.

Steve
Sep 28 '06 #21

P: n/a
Steve Pope wrote:
>
I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.
But the compiler can do that on its internal representation.
>
This was not so bad in C, since you would typically declare them all
at the beginning of the function's block, and the compiler would
place
them in registers until it ran out. In C++, with vairables declared
willy-nilly throughout the function, the register keyword is more
useful.
I would say that it is less useful, because the compiler can easíly
change the register allocation halfway through the function. The
programmer cannot.
Bo Persson
Sep 28 '06 #22

P: n/a
toton wrote:
peter koch wrote:
>toton wrote:
[snip]
>>Or may be someday
compiler will compile the program, ask user to run a few standard
run, collect the stats and reoptimize the program based on that. A
SemiJIT or CachedJIT, whatever you call it :)
This is done today already.
Which compiler do it for C++? I only know IBM Java VM cache the
Jitted
code from first run of the Java program, for subsiquent runs. Not
aware of any other compiler (C++ or any other language), which ask
user or programmer for a few "typical run" of the program and
optimize the code. This is something like optimizing the code
statically, before actual run, based on standard run for specific
processor architecture. Interested to hear about such AOT compilers
or some reference to them. :)
Both Intel's and MS' C++ compilers will do that. The programmer first
peforms a few "typical runs" to collect profile data, and then
recompiles.
Bo Persson
Sep 28 '06 #23

P: n/a

toton skrev:
peter koch wrote:
toton wrote:
[snip]
Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it :)
>
This is done today already.
Which compiler do it for C++?
The new Microsoft compiler does so - and there probably are other (I'd
be surprised if Intel did not use the same trick).
/Peter
[snip]

Sep 28 '06 #24

P: n/a
"toton" <ab*******@gmail.comwrites:
peter koch wrote:
toton wrote:
[snip]
Or may be someday compiler will compile the program, ask user to
run a few standard run, collect the stats and reoptimize the
program based on that. A SemiJIT or CachedJIT, whatever you call
it :)
>
This is done today already.

Which compiler do it for C++? I only know IBM Java VM cache the
Jitted code from first run of the Java program, for subsiquent runs.
[...]

IIRC GCC has had this for a while. I've never used it, and don't
know the details, but it's something to do with the 'gcov' code
coverage tool and the -fprofile-arcs -ftest-coverage options. I
think this has been available for several years.

----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
Sep 28 '06 #25

P: n/a
Bo Persson <bo*@gmb.dkwrote:
>
Both Intel's and MS' C++ compilers will do that. The programmer first
peforms a few "typical runs" to collect profile data, and then
recompiles.
I made a test for a while and the gain was not very good:
compiling lame using PGO give me 1-2% more speed...
For application which are not manually tuned, I get some times 10%
but I think that the effort needed (running samples, recompiling, ...)
to use this feature is too high.
------------------------------------------
CoverageMeter Software Factory
Code Coverage Tool for C/C++ <
Homepage: http://www.coveragemeter.com
------------------------------------------
Oct 2 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.