«

christian.bau wrote:
) Well, this is rubbish. If I have a 2000 line function, and then write
) a fifty line function that calls the 2000 line function 50 times, and
) then write another fifty line function that calls the previous
) function inline, and then twice more, then your compiler will just
) crash without any good reason.

No, it will crash because you *SPECIFICALLY TOLD* the compiler
to inline all those function calls.

) And if I just have a function that does fifty calls in a row to the
) 2000 line function, then the code will probably run ten times slower
) because it overruns all caches.

Irrelevant. If the programmer specifically requests that a function
be inlined, then who is the compiler to question that request ?

If the code runs ten times slower because the programmer added an inline
keyword in the wrong place, then that's *the programmer's fault*.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On Jan 30, 1:37*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> On Jan 30, 8:24*am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>
> > Depends on the machine code, but normally the call/return structure is
> > something to help human programmers organise code, not something the
> > machine needs. Even if the function is called in multiple places the
> > code bloat is unlikely to be significant - 2000 lines will compile to
> > a few thousand instructions, so tens of kilobytes machine code. Not
> > much if you've 2GB to play with.
>
> In other words, we don't need optimising compilers because processors
> are fast enough.
>
> Well, this is rubbish. If I have a 2000 line function, and then write
> a fifty line function that calls the 2000 line function 50 times, and
> then write another fifty line function that calls the previous
> function inline, and then twice more, then your compiler will just
> crash without any good reason.
>
> And if I just have a function that does fifty calls in a row to the
> 2000 line function, then the code will probably run ten times slower
> because it overruns all caches.

On Jan 30, 1:37*pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
>
> And if I just have a function that does fifty calls in a row to the
> 2000 line function, then the code will probably run ten times slower
> because it overruns all caches.
>
These sorts of micro-optimisation tradeoffs change all the time. You
might be right today, wrong on the next processor to be produced.

On 01/30/2011 06:48 AM, Willem wrote:
> christian.bau wrote:
> ) Well, this is rubbish. If I have a 2000 line function, and then write
> ) a fifty line function that calls the 2000 line function 50 times, and
> ) then write another fifty line function that calls the previous
> ) function inline, and then twice more, then your compiler will just
> ) crash without any good reason.
>
> No, it will crash because you *SPECIFICALLY TOLD* the compiler
> to inline all those function calls.

No, he did not, the "inline" keyword does not request that the function
be inlined. It "suggests that calls to the function be as fast as
possible". If inlining a particular function would make it slower, then
for that particular function, the "inline" keyword is a suggestion that
inlining NOT be performed, counterintuitive though that may seem.
It's just a suggestion, so failing to honor would not render the
compiler non-conforming; but it counts as poor QoI.

> ) And if I just have a function that does fifty calls in a row to the
> ) 2000 line function, then the code will probably run ten times slower
> ) because it overruns all caches.
>
> Irrelevant. If the programmer specifically requests that a function
> be inlined, then who is the compiler to question that request ?

C does not provide a keyword for requesting that a function be inlined;
the 'inline' keyword is certainly not such a keyword; as shown above, it
sometimes explicit suggests that the code NOT be inlined. If a new
keyword were created for requesting inlining, regardless of the effect
on the speed of the code (perhaps it could be called
_inline_even_if_slower), then use of that keyword would carry the
implications you've mistakenly concluded about the "inline" keyword.

--
James Kuyper

On 01/31/11 01:22 AM, Malcolm McLean wrote:
> On Jan 30, 1:37 pm, "christian.bau"<christian....@cbau.wanadoo.co. uk>
> wrote:
>>
>> And if I just have a function that does fifty calls in a row to the
>> 2000 line function, then the code will probably run ten times slower
>> because it overruns all caches.
>>
> These sorts of micro-optimisation tradeoffs change all the time. You
> might be right today, wrong on the next processor to be produced.

ten times slower != micro-optimisation trade-off.

That is why it is best to leave the choice of what to inline to the
compiler.

--
Ian Collins

On 01/28/2011 09:56 PM, wrote:
> Inline must be no more than a hint and cannot be unconditional. Just
> think of what would happen if you declared a recursive function inline.

The inline specifier doesn't mean "always expand this function in-line"
for exactly that reason. For recursive functions a plausible
interpretation might be "use tail-call optimisations". Or "sorry, boss;
I'm already going as fast as I can."

--Joel

On Jan 30, 9:42*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 01/31/11 01:22 AM, Malcolm McLean wrote:
>
> > On Jan 30, 1:37 pm, "christian.bau"<christian....@cbau.wanadoo.co. uk>
> > wrote:
>
> >> And if I just have a function that does fifty calls in a row to the
> >> 2000 line function, then the code will probably run ten times slower
> >> because it overruns all caches.
>
> > These sorts of micro-optimisation tradeoffs change all the time. You
> > might be right today, wrong on the next processor to be produced.
>
> ten times slower != micro-optimisation trade-off.
>
That's a common misconception. Micro-optimisation refers to the type
of optimisation (the scheduling of machine code instructions, as
opposed to algorithmic optimisation - reduction of the big-O runtime
of the algorithm or precalculation of results). Not to the percentage
speed-up obtained.