TITLE: Looping and inlining


[ previous discussion about matrix classes omitted. -adc ]


PROBLEM: Mike.Chapman@muc.de

Ah, I doubt you will get anything like operator* for matrices inlined
(at least not if you would like to get the correct result).  Loops are not
allowed in inline functions (at least as far as the ANSI proposal is
concerned).


RESPONSE: pef@fluent.com (Paul Felix)

Wow!  Loops are not allowed?  Why would they impose that kind of limit on
inline functions?


RESPONSE: clamage@taumet.Eng.Sun.COM (Steve Clamage)

There is no such restriction in the language. There is also no requirement
that a function declared inline be evaluated inline. What it might mean
for a function to be evaluated inline is also not defined. There is very
little than can be portably said about it, and no portable program can
detect whether a function was generated inline.

For example, what does it mean for an interpreter to evaluate a function
inline? Every statement is a function call (or equivalent) anyway!

Most compilers as a practical matter do not inline functions which
contain a loop, switch, or goto. A function is usually inlined by
substituting a single expression for the function body. The function
call might be part of an expression, after all, as in
	x = a() + b()/c()
where a, b, and c might be inline functions. An expression cannot
contain a loop, switch, or goto, since they are statements, not
expression elements. 'If' statements are less of a problem, since
	if( e ) t; else f;
can be converted to
	( (e) ? (t) : (f) )
as long as 't' and 'f' can each be converted to an expression. Also,
a statement sequence can be converted to a comma-expression if each
statement can be converted to an expression:
	a ; b ; c	===>	(a), (b), (c)

These transformations are not to be taken as source transformations, but
as a description of the actual internal transformation. There are no
such simple transformations available for loops, and it takes special
effort and a change in usual compiler design to support loops in inline
functions.

Finally, what is the benefit of inlining a function? You elminate the
call/return mechanism. If the time to execute the function body is large
compared to the time to call an out-of-line function, there is no benefit
to inlining it. A function containing a loop is unlikely to benefit from
inlining, since the loop overhead alone is likely to be comparable to the
cost of calling the function. (Please don't post examples of functions
with loops which are executed only once.)


RESPONSE: pef@fluent.com (Paul Felix)

Well, when you're trying to speed up SciComp code wherever possible,

	(loop overhead) < (loop overhead) + (function call overhead)

We're so close to throwing away macros forever with inline functions.  We
just need a C++ compiler that will go the extra mile to make it all worth it.


RESPONSE: clamage@taumet.Eng.Sun.COM (Steve Clamage), 26 Jul 94

1. Nothing prevents a compiler implementor from providing inlining for
any kind of function. Requiring particular behavior of a compiler in the
Standard is another matter. This is a "quality of implementation" issue,
and users can vote with their purchase orders for features they want.

2. Inlining large functions can have a negative impact on program
performance when a single function begins to exceed cache and page
limits. Calling an out-of-line function might be faster on some systems,
slower on others. Blindly insisting on inlining is not a good idea. One
should expect the compiler to make a semi-intelligent trade-off decision.

3. Omitting the function call overhead for a function which takes a long
time to execute will not have a measureable effect on program performance.
The difference will be swamped by other factors.

4. You can't use macros instead of inline functions to get loops in the
general case anyway, so the last statement seems irrelevant.

Finally, compiler implementors have to make lots of tradeoffs. Resources
are limited, and need to be spent on things which provide the maximum
benefit for most users. This is an engineering and marketing issue, and
different vendors have different kinds of customers and make different
tradeoffs. On a non-vectorizing computer with very fast function calls
(a typical risc machine), inlining loops gives little payback. On
a computer designed for parallel computation and vectorized loops, it
might make a great deal of sense to spend the effort in the compiler.