www.digitalmars.com         C & C++   DMDScript  

D - Why no inline?

reply "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
Sep 07 2002
parent reply "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

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

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

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

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

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

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

 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

 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

 able to inline those. :)

Yes, those are inlinable!
Sep 07 2002
parent reply "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

 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

 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


 be
 able to inline those. :)

Yes, those are inlinable!

cool, but how about letting us know if they are! chris
Sep 07 2002
parent reply "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

 an inline and know if it is sucesfull.


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.
Sep 07 2002
parent reply "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

 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
Sep 09 2002
next sibling parent reply "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

 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

 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

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

 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


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


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

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

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

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

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


the job.

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

 the former is any replacment for the latter.

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

 it is not an issue for most people?

 thanks for answering my questions :)

 chris

Sep 09 2002
parent reply "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

 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.
Sep 09 2002
parent reply "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

 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


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


 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,

 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.

Sep 10 2002
parent "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.
Sep 10 2002
prev sibling parent reply "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.
Sep 09 2002
parent reply "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

 assignments.

Sep 10 2002
parent "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,

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

 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

 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.
Sep 10 2002