Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Disadvantage of using 'inline'

Reply
Thread Tools

Disadvantage of using 'inline'

 
 
Method Man
Guest
Posts: n/a
 
      09-24-2004
If I don't care about the size of my executable or compile time, is there
any reason why I wouldn't want to inline every function in my code to make
the program run more efficient?


 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      09-24-2004
In <flS4d.1112$(E-Mail Removed)> "Method Man" <(E-Mail Removed)> writes:

>If I don't care about the size of my executable or compile time, is there
>any reason why I wouldn't want to inline every function in my code to make
>the program run more efficient?


1. inline is not a portable feature of C.

2. There is no guarantee that inlining everything is going to speed up
your code. Larger executable means less efficient usage of the
processor cache.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
Currently looking for a job in the European Union
 
Reply With Quote
 
 
 
 
Andrey Tarasevich
Guest
Posts: n/a
 
      09-24-2004
Method Man wrote:
> If I don't care about the size of my executable or compile time, is there
> any reason why I wouldn't want to inline every function in my code to make
> the program run more efficient?


Thoughtless inlining might easily cause code bloat, which will make your
program run _less_ efficiently.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
kyle york
Guest
Posts: n/a
 
      09-24-2004
Greetings,

Dan Pop wrote:
> In <flS4d.1112$(E-Mail Removed)> "Method Man" <(E-Mail Removed)> writes:
>
>
>>If I don't care about the size of my executable or compile time, is there
>>any reason why I wouldn't want to inline every function in my code to make
>>the program run more efficient?

>
>
> 1. inline is not a portable feature of C.


Odd, I must be horribly misreading 6.7.4: Function specifiers


--
Kyle A. York
Sr. Subordinate Grunt, SC
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-24-2004
kyle york <(E-Mail Removed)> writes:
> Greetings,
> Dan Pop wrote:
>> In <flS4d.1112$(E-Mail Removed)> "Method Man" <(E-Mail Removed)> writes:
>>
>>>If I don't care about the size of my executable or compile time, is there
>>>any reason why I wouldn't want to inline every function in my code to make
>>>the program run more efficient?

>> 1. inline is not a portable feature of C.

>
> Odd, I must be horribly misreading 6.7.4: Function specifiers


His point is that "inline" is a new feature in C99, not supported by
C90, and that C99 compilers are not yet widespread enough for code
that depends on C99-specific features to be considered portable.

On the other hand, many compilers that don't support all of C99 do
support inline (whether they do so in a way that's 100% compatible
with the C99 specification is another question).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Derrick Coetzee
Guest
Posts: n/a
 
      09-24-2004
Method Man wrote:
> If I don't care about the size of my executable or compile time, is there
> any reason why I wouldn't want to inline every function in my code to make
> the program run more efficient?


Disclaimer: Parts of this response may be platform-specific.

Actually, many compilers *do* aggressively inline small functions within
a module at high optimization levels, even if you don't explicitly ask
them to. For example, gcc does this at -O3 (which includes the flag
-finline-functions, the primary difference from -O2).

No good compiler will inline a large function, though, even if you ask
it to, not only because of the large space overhead in doing so but
because the purpose of inlining is to eliminate function call overhead,
and this is simply relatively insigificant if enough time is spent
inside the function called (even a small function with a long loop
doesn't benefit from inlining).

Placing the inline keyword on all static (module-local) functions is an
okay thing to do, if you trust your compiler; it'll figure out when not
to do it, although you can't take an inline function's address to call
it indirectly, and you'll look a bit silly. Trouble starts when you
attempt to export an inline function, though, and use it in multiple
modules. Such an inline function has to include its definition in every
module using it, usually via a header. If the compiler ends up not
inlining it, for whatever reason, this may result in a copy of its code
being placed in every module that uses it. Thus you should only export
small inline functions.
--
Derrick Coetzee
I grant this newsgroup posting into the public domain. I disclaim all
express or implied warranty and all liability. I am not a professional.
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      09-25-2004
Derrick Coetzee wrote:
> ...
> Placing the inline keyword on all static (module-local) functions is an
> okay thing to do, if you trust your compiler; it'll figure out when not
> to do it, although you can't take an inline function's address to call
> it indirectly, and you'll look a bit silly.


While it is true that an indirect call cannot be inlined (for obvious
reasons), there is absolutely no problem with taking an address of an
inline function. You seem to be mistaking two different things: inline
functions and inlined calls to functions.

> Trouble starts when you
> attempt to export an inline function, though, and use it in multiple
> modules. Such an inline function has to include its definition in every
> module using it, usually via a header. If the compiler ends up not
> inlining it, for whatever reason, this may result in a copy of its code
> being placed in every module that uses it. Thus you should only export
> small inline functions.


That would be true in C++, but that's not necessarily true in C (C99).
An inline function with external linkage in C can have external
definition in addition to inline definition. The external definition can
be reached from other translation units (by non-inline calls, of course).

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      09-25-2004
Method Man wrote:

> If I don't care about the size of my executable or compile time,
> is there any reason why I wouldn't want to inline every function in my code
> to make the program run more efficient?


No.
You may find that you want to define than as "inline static"
in a header file so that you don't get "multiply defined references".

The idea behind inline functions is to encourage programmers
to decompose functions into smaller functions
and let the compiler "inline" them automatically
instead of inlining them manually.
This should result in code
that is easier to read, understand and maintain
while maximizing performance and efficiency.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-25-2004
"E. Robert Tisdale" wrote:
> Method Man wrote:
>
>> If I don't care about the size of my executable or compile time,
>> is there any reason why I wouldn't want to inline every function
>> in my code to make the program run more efficient?

>
> No.
> You may find that you want to define than as "inline static"
> in a header file so that you don't get "multiply defined references".


If the function is static there is no point in mentioning it in
any header file. Headers should be used solely to export things
from a compilation unit. Static functions are not accessible
outside the compilation unit.

>
> The idea behind inline functions is to encourage programmers to
> decompose functions into smaller functions and let the compiler
> "inline" them automatically instead of inlining them manually.
> This should result in code that is easier to read, understand and
> maintain while maximizing performance and efficiency.


This is accurate.

--
"It is not a question of staying the course, but of changing
the course" - John Kerry, 2004-09-20
"Ask any boat owner the eventual result of continuing the
present course indefinitely" - C.B. Falconer, 2004-09-20


 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      09-25-2004
(E-Mail Removed) (Dan Pop) wrote in message news:<cj0v6s$boq$(E-Mail Removed)>...
> In <flS4d.1112$(E-Mail Removed)> "Method Man" <(E-Mail Removed)> writes:
>
> >If I don't care about the size of my executable or compile time, is there
> >any reason why I wouldn't want to inline every function in my code to make
> >the program run more efficient?

>
> 1. inline is not a portable feature of C.
>
> 2. There is no guarantee that inlining everything is going to speed up
> your code. Larger executable means less efficient usage of the
> processor cache.
>


A larger executable may mean less efficient usage of the processor
cache, but it may not. As an obvious example, judicious loop
unrolling (by the compiler) often causes larger code, but faster code.
Of course, everything in moderation: if you unroll too much you will
cause icache (or trace cache) thrashing because your working sets keep
pushing each other out. That's really the essence of what Dan was
getting at.

As usual, there's a bunch of competing factors. Inlining small,
frequently *called* functions may be beneficial because it eliminates
function call overhead and allows CSE and other optimizations to be
performed within the context of the caller. This could translate to
fewer branches, which reduces the likelihood of mispredicted branches,
which can be costly.

Now I just said small, frequently *called* functions, but I did not
mean frequently *used* functions, unless they're so small that
function call overhead is more than, or a significant percentage of,
their execution time. By frequently used functions, I mean the ones
you find sprinkled all over the code, but not typically in performance
sensitive areas. These are what you do not want to inline, because
the code bloat is not worth it.

One big problem is that your inline function looks like a function to
you, and in the source code, but not to the processor. Inline
functions will not cause a hot spot in the cache. They decrease
locality. If your program calls a frequently used inline function
twice reasonably near each other, for example, the second call will
*not* find the function already sitting in cache, ready to go.
Granted, hardware prefetch may cause this to be a moot point in some
cases, but then again, the hardware prefetch would then be fetching
something that should already be in the cache, and displacing
something else that may be beneficial.

So what can you inline? Well, the best functions to inline are the
ones that are used exactly once and are static. It's hard to go wrong
with that. With anything else, you need to profile your code and be
familiar with the relative costs your architecture imposes on you. As
always, when in doubt, check your compiler's assembly output. You may
be pleasantly surprised to find that your compiler is good at figuring
out which functions to inline for you, under certain optimization
levels. And if you religiously use static functions, as you should,
the compiler has a much easier time at doing just that.

If you're serious about code performance, you need to be familiar with
the applicable profiling tools and with the increasingly popular
profile driven optimization. Profile driven optimization gives the
compiler a much better idea of which branches are taken and which are
not, so that it can output the best possible assembly. Now when you
combine that with profiling and subsequent inlining and tweaking, you
have the possibility of some very well performing code. But you're
not going to get that by simply inlining everything, that's for sure.


Mark F. Haigh
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there any advantage or disadvantage to using sets over list compsto ensure a list of unique entries? deathweaselx86 Python 5 06-25-2011 08:05 AM
Disadvantage of using wildcards in import statement. Dipankar Java 17 08-01-2009 02:36 PM
Another disadvantage with frames, at least on iCab... dorayme HTML 11 09-21-2005 10:45 AM
Advantage and DisAdvantage of Jakarta Strut Joe Java 3 12-05-2003 03:23 PM
Advantages/disadvantage of XD Memory Walter E. Digital Photography 3 10-31-2003 01:47 AM



Advertisments