• chris jones (17/17) Sep 07 2002 Why has the inline keyword been droped? For alot of programers i think t...
• Walter (16/32) Sep 07 2002 this
• chris jones (11/26) Sep 07 2002 should
• Walter (13/22) Sep 07 2002 Nope. But it can make a good enough decision, consistently applied over ...
• chris jones (23/39) Sep 09 2002 drudgery
• Sean L. Palmer (21/64) Sep 09 2002 I just hate it when you use all tools available to suggest inlining,
• Walter (7/14) Sep 09 2002 STILL
• Sean L. Palmer (12/27) Sep 10 2002 It's a fault of the language, because that it's unspecified behavior. T...
• Walter (29/34) Sep 10 2002 The language specifies a certain semantic meaning, which should be the s...
• Walter (5/5) Sep 09 2002 Enregistering a variable is deciding which variables get put wholly in
• Sean L. Palmer (17/22) Sep 10 2002 Yeah and now we have the need for the "volatile" keyword. ;) To tell t...
• Walter (8/21) Sep 10 2002 That one's going on in another thread at the moment .

"chris jones" <flak clara.co.uk> writes:

Why has the inline keyword been droped? For alot of programers i think this
will be a problem because it is fairly esential for fast coding, eg dsp and
math. Surely the programer should be able to have some controll over this! I
understand that the compiler is best deciding when code is not inlined but i
think the programer should be able to request that a function is inlined. At
the moment the programer has very little to go on and would have to look at
the generated asm to to actualy find out whether a function gets inlined. So
i have a proposal!

1. have definate rules as to what can and cant be inlined.
2. use the inline keyword as a request (as it is in C++ i think)
3. have the compiler generate a warning when a requested inline fails!

I am not wanting to force the compiler to inline but i would like to request
an inline and know if it is sucesfull.

What about asm inlines, are they posible? I mean if you have a pure asm
function or naked as the specs call it, it would be an exelent feature to be
able to inline those. :)

chris

"Walter" <walter digitalmars.com> writes:

"chris jones" <flak clara.co.uk> wrote in message
news:ald2nh$1c8q$1 digitaldaemon.com...
 Why has the inline keyword been droped? For alot of programers i think

this
 will be a problem because it is fairly esential for fast coding, eg dsp

and
 math. Surely the programer should be able to have some controll over this!

I
 understand that the compiler is best deciding when code is not inlined but

i
 think the programer should be able to request that a function is inlined.

At
 the moment the programer has very little to go on and would have to look

at
 the generated asm to to actualy find out whether a function gets inlined.

So
 i have a proposal!

 1. have definate rules as to what can and cant be inlined.
 2. use the inline keyword as a request (as it is in C++ i think)
 3. have the compiler generate a warning when a requested inline fails!

The inline keyword was dropped because it is as obsolete as the 'register'
keyword in C, for analogous reasons - it's an optimization issue that should
be decided by the compiler.

 I am not wanting to force the compiler to inline but i would like to

request
 an inline and know if it is sucesfull.

The only way to do that now is to obj2asm the output.

 What about asm inlines, are they posible? I mean if you have a pure asm
 function or naked as the specs call it, it would be an exelent feature to

be
 able to inline those. :)

Yes, those are inlinable!

"chris jones" <flak clara.co.uk> writes:

"Walter" <walter digitalmars.com> wrote in message
news:aldal3$1t1f$1 digitaldaemon.com...
 1. have definate rules as to what can and cant be inlined.
 2. use the inline keyword as a request (as it is in C++ i think)
 3. have the compiler generate a warning when a requested inline fails!

 The inline keyword was dropped because it is as obsolete as the 'register'
 keyword in C, for analogous reasons - it's an optimization issue that

should
 be decided by the compiler.


Are you saying the compiler can make a better choice all the time?

Am I being niave in thinking i can optimise my code better than the
compiler?

 I am not wanting to force the compiler to inline but i would like to

 request
 an inline and know if it is sucesfull.

 The only way to do that now is to obj2asm the output.

Do you think the programer should have to resort to obj2asm to find out
whether inlining was done?


 What about asm inlines, are they posible? I mean if you have a pure asm
 function or naked as the specs call it, it would be an exelent feature


to
 be
 able to inline those. :)

 Yes, those are inlinable!

cool, but how about letting us know if they are!

chris

"Walter" <walter digitalmars.com> writes:

"chris jones" <flak clara.co.uk> wrote in message
news:ale6is$r31$1 digitaldaemon.com...
 Are you saying the compiler can make a better choice all the time?

Nope. But it can make a good enough decision, consistently applied over the
entire project.

 Am I being niave in thinking i can optimise my code better than the
 compiler?

Nope. No compiler can beat a crackerjack programmer, not even close. But
when you've got thousands of functions, who wants to make all those drudgery
decisions? Let the compiler do it.

 I am not wanting to force the compiler to inline but i would like to

 request
 an inline and know if it is sucesfull.

 The only way to do that now is to obj2asm the output.

 Do you think the programer should have to resort to obj2asm to find out
 whether inlining was done?

Yes. Inlining or not inlining isn't any different from enregistering a
variable or not. The payoff tradeoffs for inlining or not vary depending on
compiler switches, CPU versions, memory, different CPU types, etc. Let the
compiler make those decisions.

For when you really need total control, the inline assembler is perfect for
the job.

"chris jones" <flak clara.co.uk> writes:

"Walter" <walter digitalmars.com> wrote in message
news:aler6k$284h$1 digitaldaemon.com...
 "chris jones" <flak clara.co.uk> wrote in message
 news:ale6is$r31$1 digitaldaemon.com...
 Are you saying the compiler can make a better choice all the time?

 Am I being niave in thinking i can optimise my code better than the
 compiler?

 Nope. No compiler can beat a crackerjack programmer, not even close. But
 when you've got thousands of functions, who wants to make all those

drudgery
 decisions? Let the compiler do it.

The compiler will still make these desicions where the programmer has not
requested an inline. In most programs there are small amount functons that
do most of the work. Say if you are writing an image procesing library mabey
only 10% of the code is doing 90% of the work and it is that code which we
need the controll over. In dsp algorythms math functions are used very
frequently and inlining can be a very significant performance boost, but the
code for the algorythm may be a tiny percentage of the code of the complete
program.

 Do you think the programer should have to resort to obj2asm to find out
 whether inlining was done?

Yes. Inlining or not inlining isn't any different from enregistering a
variable or not. The payoff tradeoffs for inlining or not vary depending on
compiler switches, CPU versions, memory, different CPU types, etc. Let the
compiler make those decisions.

Im not sure what enregistering a variable means. But as you say the payoff
of inlining varies on many things, of which i have doubts as to whether any
compilers take into acount.  The Borland compilers dont even use cmov. I
only know of one compiler that can target either AMD or Pentium instruction
sets. So i dont see there is any usefull decision being made by the compiler
unless you intend to include compiler options for targeting diferant CPUs?

For when you really need total control, the inline assembler is perfect for
the job.

Inline assembler and inline functions are two valuable tools i cant see that
the former is any replacment for the latter.

I get the feeling i wont change your mind so i will leave it at that. Mabey
it is not an issue for most people?

thanks for answering my questions :)

chris

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

I just hate it when you use all tools available to suggest inlining,
strongly suggest inlining, force inlining, and the god damned compiler STILL
ignores you and doesn't inline the empty constructor or some bullshit.  ;)

To date I haven't seen any compilers that could be trusted to do the right
thing.  They aren't smart enough to know how a function is being used, and
what calls are speed critical and which ones aren't.  That's only known
after extensive profiling.

Sean

"chris jones" <flak clara.co.uk> wrote in message
news:alifp0$tg9$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:aler6k$284h$1 digitaldaemon.com...
 "chris jones" <flak clara.co.uk> wrote in message
 news:ale6is$r31$1 digitaldaemon.com...
 Are you saying the compiler can make a better choice all the time?

 Am I being niave in thinking i can optimise my code better than the
 compiler?

 Nope. No compiler can beat a crackerjack programmer, not even close. But
 when you've got thousands of functions, who wants to make all those

 drudgery
 decisions? Let the compiler do it.

 The compiler will still make these desicions where the programmer has not
 requested an inline. In most programs there are small amount functons that
 do most of the work. Say if you are writing an image procesing library

mabey
 only 10% of the code is doing 90% of the work and it is that code which we
 need the controll over. In dsp algorythms math functions are used very
 frequently and inlining can be a very significant performance boost, but

the
 code for the algorythm may be a tiny percentage of the code of the

complete
 program.

 Do you think the programer should have to resort to obj2asm to find out
 whether inlining was done?

Yes. Inlining or not inlining isn't any different from enregistering a
variable or not. The payoff tradeoffs for inlining or not vary depending


on
compiler switches, CPU versions, memory, different CPU types, etc. Let


the
compiler make those decisions.

 Im not sure what enregistering a variable means. But as you say the payoff
 of inlining varies on many things, of which i have doubts as to whether

any
 compilers take into acount.  The Borland compilers dont even use cmov. I
 only know of one compiler that can target either AMD or Pentium

instruction
 sets. So i dont see there is any usefull decision being made by the

compiler
 unless you intend to include compiler options for targeting diferant CPUs?

For when you really need total control, the inline assembler is perfect


for
the job.

 Inline assembler and inline functions are two valuable tools i cant see

that
 the former is any replacment for the latter.

 I get the feeling i wont change your mind so i will leave it at that.

Mabey
 it is not an issue for most people?

 thanks for answering my questions :)

 chris

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:alimpf$1ldk$1 digitaldaemon.com...
 I just hate it when you use all tools available to suggest inlining,
 strongly suggest inlining, force inlining, and the god damned compiler

STILL
 ignores you and doesn't inline the empty constructor or some bullshit.  ;)

 To date I haven't seen any compilers that could be trusted to do the right
 thing.  They aren't smart enough to know how a function is being used, and
 what calls are speed critical and which ones aren't.  That's only known
 after extensive profiling.

Most functions that are the best candidates for inlining, when inlined, are
always an improvement in both size and speed. Empty functions are a prime
example, as are functions that consist of a single, simple expression. Not
inlining them is a fault in the compiler, not a fault in the language.

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

It's a fault of the language, because that it's unspecified behavior.  The
inline keyword is merely a suggestion.

I want an inline keyword with the meaning "inline this or give me one good
reason why you can't, as a warning".  That permits platform specific
behavior but is easier to manage.  Eliminates lots of guesswork.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:alio6i$1q78$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:alimpf$1ldk$1 digitaldaemon.com...
 I just hate it when you use all tools available to suggest inlining,
 strongly suggest inlining, force inlining, and the god damned compiler

 STILL
 ignores you and doesn't inline the empty constructor or some bullshit.


;)
 To date I haven't seen any compilers that could be trusted to do the


right
 thing.  They aren't smart enough to know how a function is being used,


and
 what calls are speed critical and which ones aren't.  That's only known
 after extensive profiling.

 Most functions that are the best candidates for inlining, when inlined,

are
 always an improvement in both size and speed. Empty functions are a prime
 example, as are functions that consist of a single, simple expression. Not
 inlining them is a fault in the compiler, not a fault in the language.

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:alk75k$1noo$1 digitaldaemon.com...
 It's a fault of the language, because that it's unspecified behavior.  The
 inline keyword is merely a suggestion.

The language specifies a certain semantic meaning, which should be the same
regardless of whether inlining happens or not.

 I want an inline keyword with the meaning "inline this or give me one good
 reason why you can't, as a warning".  That permits platform specific
 behavior but is easier to manage.  Eliminates lots of guesswork.

As compilers improve, this issue should become completely moot. Also, I
expect most D compilers to be based on the open D source, which implements
inlining and so should provide that as a minimum.

When I profile code, I always wind up disassembling the bottlenecks anyway
to see if there is some unexpected inefficient code being generated. I'm not
convinced that one can write high performance code in a high level language
without knowing the corresponding machine code. For example, I know a fellow
who wrote his first program, a program to write some strings out to a file.
For each character, he opened the file, appended the character, and closed
the file. It ran fantastically slowly, of course. He asked a friend to
examine his code and tell him why it was so slow. When it was explained, he
replied that the manuals for the file I/O functions said nothing at all
about how to do efficient file I/O or the tradeoffs involved. He was right.

Analogously, to write high performance code, you'll need to get familiar
with how your particular compiler generates code for particular language
constructs. No way around it - and you can certainly find yourself
implementing the same algorithm in different ways for different
compilers/systems due to different ways code is generated.

Inlining is only one part of a much larger code generation issue, such as
register allocation, addressing modes, instruction scheduling, etc., all
interacting with each other.

It is a good idea to have some kind of slider that changes optimization
between size and speed, but that such should be on a per-module basis. A
higher desired speed / size ratio would cause the compiler to do more
aggressive inlining.

"Walter" <walter digitalmars.com> writes:

Enregistering a variable is deciding which variables get put wholly in
registers rather than allocated on the stack. Early C compilers used the
'register' keyword to indicate which variables should be enregistered. All
modern compilers that I know of ignore the keyword and do their own register
assignments.

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

Yeah and now we have the need for the "volatile" keyword.  ;)  To tell the
compiler to not enregister a variable.

Ignoring potentially important hints doesn't seem very smart, to me.  At
least with volatile usually the language has to commit to some behavior, has
to give you some guarantee.  The inline hint can have any effect from doing
it to not doing it, to maybe having done it, to warning you about it, or
not; a large range, and no guarantees.

I can give you one damn good reason for not inlining automatically... it
makes a module link-dependent on another module it uses inline functions
from.  It increases coupling.  From a security standpoint it gives out too
much information.  It's really only appropriate for private classes within a
module, or if you absolutely must have speed at the expense of privacy and
interdependence.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:alio6i$1q78$2 digitaldaemon.com...
 Enregistering a variable is deciding which variables get put wholly in
 registers rather than allocated on the stack. Early C compilers used the
 'register' keyword to indicate which variables should be enregistered. All
 modern compilers that I know of ignore the keyword and do their own

register
 assignments.

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:alk82e$1olk$1 digitaldaemon.com...
 Yeah and now we have the need for the "volatile" keyword.  ;)  To tell the
 compiler to not enregister a variable.

That one's going on in another thread at the moment <g>.

 Ignoring potentially important hints doesn't seem very smart, to me.  At
 least with volatile usually the language has to commit to some behavior,

has
 to give you some guarantee.  The inline hint can have any effect from

doing
 it to not doing it, to maybe having done it, to warning you about it, or
 not; a large range, and no guarantees.

 I can give you one damn good reason for not inlining automatically... it
 makes a module link-dependent on another module it uses inline functions
 from.  It increases coupling.  From a security standpoint it gives out too
 much information.  It's really only appropriate for private classes within

a
 module, or if you absolutely must have speed at the expense of privacy and
 interdependence.

You're right. You can prevent inlining by not specifying functions being
'final' or by not specifying the body of the function in the import file.