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

"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!

"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

"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.

"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

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
>
>
>
>
>
>

"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.

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.

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.

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.