Don't use inline functions
Jeff Connelly
Minutes, please. The book claims to teach ISO/ANSI Standard C++. I am
not taking this out of context - no further explanation is given, such
as what exactly should be done with various compilers to get the
optimization he refers to.
"Do not use inline functions. The compiler is better at optimizing your
code than you think. Avoid using inline functions; let the compiler
make your code run as fast as you can."
--
Regards,
Jeff
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Thomas_...@tecmar.com
Jeff Connelly <jeff_c...@mgv.com> wrote:
> Your comments on the following quote from SAMS Teach Yourself C++ in
10
> Minutes, please. The book claims to teach ISO/ANSI Standard C++. I
am
> not taking this out of context - no further explanation is given, such
> as what exactly should be done with various compilers to get the
> optimization he refers to.
>
> "Do not use inline functions. The compiler is better at optimizing
your
> code than you think. Avoid using inline functions; let the compiler
> make your code run as fast as you can."
I suggest you use inline functions. The "inline" modifier is a
SUGGESTION to the compiler to inline the function. The compiler will
inline if it wants to, depending on the set optimization level. The
general rule is to make simple functions inline; complex ones don't mark
as inline.
Now, if you are concerned with performance issues, start at the design
level. Can you optimize the design of your algorithms? Can you code an
algorithm more efficiently? Inlining an efficient function doesn't add
anything to the performance of a program. If you can't optimize the
design, the use a profiler tool to find the section where most of the
time is spent and optimize that part. If you are truly desparate,
convert the function to assembly (providing you can do a better job than
the compiler). Just remember that most of the improvements in
performance come from improving the design and eliminating redundancy
and dead code areas.
Shiva
Jeff Connelly wrote:
>
> Your comments on the following quote from SAMS Teach Yourself C++ in 10
> Minutes, please. The book claims to teach ISO/ANSI Standard C++. I am
> not taking this out of context - no further explanation is given, such
> as what exactly should be done with various compilers to get the
> optimization he refers to.
>
> "Do not use inline functions. The compiler is better at optimizing your
> code than you think. Avoid using inline functions; let the compiler
> make your code run as fast as you can."
This is absolutely wrong. The inline keyword was introduced because the
compilers are not good at doing this.
I had started a discussion on this in march in comp.lang.c++.moderated
search in dejanews for subject "Automatic Inlining".
& you will find the thread.
--
cheers,
Shiva
http://members.xoom.com/jshiva
clc++ FAQ : http://www.cerfnet.com/~mpcline/c++-faq-lite/
blargg
> Your comments on the following quote from SAMS Teach Yourself C++ in 10
> Minutes, please. The book claims to teach ISO/ANSI Standard C++. I am
> not taking this out of context - no further explanation is given, such
> as what exactly should be done with various compilers to get the
> optimization he refers to.
>
> "Do not use inline functions. The compiler is better at optimizing your
> code than you think. Avoid using inline functions; let the compiler
> make your code run as fast as you can."
Considering the audience, it may be sound advice. I mean come on, 10 minutes?
BTW, nice gag. SAMS Where's Waldo? in 10 minutes.
Shiva
>
> Jeff Connelly wrote:
> >
> > Your comments on the following quote from SAMS Teach Yourself C++ in 10
> > Minutes, please. The book claims to teach ISO/ANSI Standard C++. I am
> > not taking this out of context - no further explanation is given, such
> > as what exactly should be done with various compilers to get the
> > optimization he refers to.
> >
> > "Do not use inline functions. The compiler is better at optimizing your
> > code than you think. Avoid using inline functions; let the compiler
> > make your code run as fast as you can."
>
> compilers are not good at doing this.
>
> I had started a discussion on this in march in comp.lang.c++.moderated
> search in dejanews for subject "Automatic Inlining".
> & you will find the thread.
>
This is what Bjarne Stroustroup said about this topic in USENET.
I didn't find this in deja news, but I had saved a copy.
------------------------------------------------------------------------
The primary reason that "inline" is in the
language is that compilers for production languages have consistently
failed to do a decent job of inlining over the last 30 years or so.
There are some reasons for that. One is that for a program composed of
separately compiled parts, the compiler doesn't have the information
needed to do the inlining. Only the linker has sufficient information,
and the linker typically lacks undestanding of what optimizations are
desirable. Note also that the most significant benefits of inlining
comes from having the optimizer work on the inlined code in the context
of a call. And the optimizer tends to run before the linker rather
than after. Slowing down the linking process (further) by adding
sophisticated optimizations would be unpopular in places.
Also, it is quite hard for a compiler to judge which time/space
tradeoffs
makes sense. Given "inline" a programmer can measure and experiement.
Finally, even if one compiler had decent inlining (and I can't think of
a
single C or C++ compiler that I'd deem good at that), people who need
consistent (high) performance over a range of platforms would need a
tool to deal with the rest. Inline comes in handy here.
You don't seem to have much trust in programmers ability to judge their
own code. In many cases that doubt may be warrented. However, *many*
programmers are quite capable of measuring the performance of their
code (in time and space) and to achieve significant improvements using
"inline."
We shouldn't deprive good programmers of a significant tool just because
poor programmers can fail to use it effectively. If you don't like
"inline"
simply don't use it - and pay whatever penalty results. If/when
implementations become good at inlining we'll all stop using "inline"
just as we stopped using "register" on major computers.
Actually, that "privelege" is simply necessary. Requiring complete
inlining
would demand the impossible of the compiler.
Maybe, but the average compiler simply doesn't do that job and those
that
do rarely do it consistently well.
- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs
----------------------------------------------------------------------------
Jeff Connelly
postmast.ro...@iname.com (blargg) wrote:
> Considering the audience, it may be sound advice. I mean come on, 10
minutes?
I skimmed the intro, but I still can't figure out what they mean by "10
minutes." I suppose just to get someone to pick up the book in the
store.
Michael Rubenstein
<jeff_c...@mgv.com> wrote:
>Your comments on the following quote from SAMS Teach Yourself C++ in 10
>Minutes, please. The book claims to teach ISO/ANSI Standard C++. I am
>not taking this out of context - no further explanation is given, such
>as what exactly should be done with various compilers to get the
>optimization he refers to.
>
>"Do not use inline functions. The compiler is better at optimizing your
>code than you think. Avoid using inline functions; let the compiler
>make your code run as fast as you can."
The advice is reasonable for the level at which the book is
written. I think there's a consensus in the C++ community that
one should not use inline functions until one has at least 14
minutes experience with the language.
Paul Black
> On Thu, 29 Jul 1999 18:50:28 GMT, Jeff Connelly
> <jeff_c...@mgv.com> wrote:
>
> >Your comments on the following quote from SAMS Teach Yourself C++ in 10
> >Minutes, please.
> I think there's a consensus in the C++ community that
> one should not use inline functions until one has at least 14
> minutes experience with the language.
ROTFL
Paul
Jeff Connelly
mik...@ix.netcom.com (Michael Rubenstein) wrote:
>I think there's a consensus in the C++ community that
> one should not use inline functions until one has at least 14
> minutes experience with the language.
Excellent!
Caius Marius
>Your comments on the following quote from SAMS Teach Yourself C++ in 10
>not taking this out of context - no further explanation is given, such
>as what exactly should be done with various compilers to get the
>optimization he refers to.
>
>"Do not use inline functions. The compiler is better at optimizing your
>code than you think. Avoid using inline functions; let the compiler
>make your code run as fast as you can."
The first and first part of the third sentences are flat out wrong. The second
is good advice.
Example:
Suppose you have a short function, 3-line function that is is speed critical
and is called from different source modules.
How would you increase the speed? (Make it inline or have the compiler
automatically inline it for you as the author suggests)
In order for it to be inline (even if the compiler does it on its own) the
function has to be in the compilation unit. How would you share it across
multiple files? (Put it in an include file.)
Try putting a non-inline function in an include file used by multiple
compilation units and see if your linker just loves you for it.
John - N8086N
Big brother is watching. Disable cookies in your web browser.
-------------------------------------------
Wise man says "Never use a bank with the initials F. U."
-------------------------------------------
Are you interested in a professional society or
guild for programmers? Want to fight section 1706?
See www.programmersguild.org
Newsgroup: us.issues.occupations.computer-programmers
EMail Address:
_m-i-a-n-o_@_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s._c_o_m_
Guenther Brunthaler
<jeff_c...@mgv.com> wrote:
>"Do not use inline functions. The compiler is better at optimizing your
>code than you think. Avoid using inline functions; let the compiler
>make your code run as fast as you can."
The problem with this statement is that that compiler CANNOT optimize
externally defined functions, because it processes each compilation
unit independently.
Even though a smart compiler could convert a non-static global
function to inline code within the same module, it still would have to
create the function-instance also, because it may be called from
outside the current compilation unit.
Of course, defining such functions as 'static' may prevent this
problem. But then there is another problem: In case the compiler
decides NOT to inline the function's code, it will create a DUPLICATE
static function for every compilation unit that defines that static
function.
And that's the big difference to inline functions: Even though they
may also be converted to real functions by the compiler if they are
considered inappropriate for inlining, they will be defined as
"shared" external functions in this case.
This means that they will be tagged for the linker in such a way that
the linker silently removes duplicates instead of complaining about
duplicate symbol definitions, as it would do if non-static functions
werde defined (and not just declared) in multiple compilation units.
Plus, there is also another reason: The compiler has not always enough
information available whether a function is indeed a good candidate
for inlining.
In such cases, the compiler may to decide to not inline a function
even though the programmer desires this.
In this context, "inline" can be interpreted very similar to
"register": It provides a hint to the compiler that *may* help
increase the code quality.
Greetings,
Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.
In order to get my public RSA PGP-key, send mail with blank body
to: pgp-pub...@keys.pgp.net
Subject: get 0x2D2F0683
Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint: 11 71 47 2F AF 2F CD F4 E6 78 D5 E5 3E DD 07 B5
Phlip
> Jeff Connelly wrote:
>
> >"Do not use inline functions. The compiler is better at
optimizing your
> >code than you think. Avoid using inline functions; let the
compiler
> >make your code run as fast as you can."
>
> The problem with this statement is that that compiler CANNOT
optimize
> externally defined functions, because it processes each
compilation
> unit independently.
The language Standard only says that source is translated and
eventually forms a binary. Although the Standard provides certain
rules for the logical effects of linkage between trans units, it
does not require one object file to be totally blind to another. You
are discussing a limitation of current linkers; these limitations
are typically legacies of the original PDP-11's linker, which was a
helplessly lame program.
> Even though a smart compiler could convert a non-static global
> function to inline code within the same module, it still would
have to
> create the function-instance also, because it may be called from
> outside the current compilation unit.
No, it can do anything it likes, so long as the result is As If the
function had one global instance. And so it conceivably can peek
into other trans units to see if the function gets called from
there.
> Of course, defining such functions as 'static' may prevent this
> problem. But then there is another problem: In case the compiler
> decides NOT to inline the function's code, it will create a
DUPLICATE
> static function for every compilation unit that defines that
static
> function.
>
> And that's the big difference to inline functions: Even though
they
> may also be converted to real functions by the compiler if they
are
> considered inappropriate for inlining, they will be defined as
> "shared" external functions in this case.
>
> This means that they will be tagged for the linker in such a way
that
> the linker silently removes duplicates instead of complaining
about
> duplicate symbol definitions, as it would do if non-static
functions
> werde defined (and not just declared) in multiple compilation
units.
Yes, and this is why nobody should say 'inline' is only a "hint" to
the compiler - it's also a linkage directive.
--
Phlip at politizen dot com (address munged)
======= http://users.deltanet.com/~tegan/home.html =======
http://users.deltanet.com/~tegan/macchu_picchu