www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: inlining or not inlining...

reply Jim <bitcirkel yahoo.com> writes:
Jonathan M Davis Wrote:


 On Thursday 10 February 2011 22:35:34 Walter Bright wrote:

 Stewart Gordon wrote:

 On 09/02/2011 12:14, spir wrote:

 Hello,
 
 Walter states that inline annotations are useless, since programmers
 cannot generally know
 which function /should/ be inlined --depending on a variety of
 factors, inlining may in
 fact be counter-productive.



 <snip>
 
 I hate not being able to force functions to be inline.  A consequence is
 that you can't fully interface certain APIs without an extra .lib over
 what would be needed in C(++).



 You cannot force inlining in C(++) either. The inline keyword is only a
 suggestion.



 True. However, IIRC -O3 in gcc forces inlining, so in some cases you _can_
force 
 it (though that's obviously compiler-specific), but forcing inlining with -O3 
 does it for _everything_, so it's not exactly precision instrument.
 
 Regardless, I would _hope_ that the compiler would be smart enough to make 
 intelligent choices about inlining. That's probably one of those areas that
can 
 always be improved however.




I also think that this decision should be left to the compiler.

The inline keyword was deemed useful for the same reason that symbols had to be
declared before their use (causing the C/C++ header hell) -- it's easier to
implement such a compiler.
Feb 11 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/11/2011 09:33 AM, Jim wrote:

 Regardless, I would _hope_ that the compiler would be smart enough to make

  intelligent choices about inlining. That's probably one of those areas that
can
  always be improved however.






 I also think that this decision should be left to the compiler.

 The inline keyword was deemed useful for the same reason that symbols had to
be declared before their use (causing the C/C++ header hell) -- it's easier to
implement such a compiler.



Agreed; but what about having the compiler tell you, on demand, "func 'f' at 
line #l in module 'm' was not inlined" ?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
parent reply Jim <bitcirkel yahoo.com> writes:
spir Wrote:


 On 02/11/2011 09:33 AM, Jim wrote:

 Regardless, I would _hope_ that the compiler would be smart enough to make

  intelligent choices about inlining. That's probably one of those areas that
can
  always be improved however.






 I also think that this decision should be left to the compiler.

 The inline keyword was deemed useful for the same reason that symbols had to
be declared before their use (causing the C/C++ header hell) -- it's easier to
implement such a compiler.



 Agreed; but what about having the compiler tell you, on demand, "func 'f' at 
 line #l in module 'm' was not inlined" ?



I rarely need to go that low-level. My hope is that the compiler will sort this
out in the end. Give it some time, or effort to have these optimizations
implemented in the compiler.
Feb 11 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jim:


 I rarely need to go that low-level.



Two times I have had D1 code that was too much slow compared to equivalent C
code. After profiling and some changes I have understood that the cause was an
important missing inline. With a list of the inlined functions (as done by
CommonLisp some compilers, see the enhancement request in Bugzilla), this
search becomes quicker.



 My hope is that the compiler will sort this out in the end. Give it some time,
or effort to have these optimizations implemented in the compiler.



The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).

Bye,
bearophile
Feb 11 2011
parent reply Jim <bitcirkel yahoo.com> writes:
bearophile Wrote:

 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).




If forced inlining is to be supported I think it would be good idea to also let
the _caller_ decide whether to inline a function. The compiler could simply
find the function definition, perhaps parameterize it, and then insert it.
Should it not be able to inline almost any function if asked to?
Feb 11 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Jim Wrote:


 bearophile Wrote:

 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).



 
 If forced inlining is to be supported I think it would be good idea to also
let the _caller_ decide whether to inline a function. The compiler could simply
find the function definition, perhaps parameterize it, and then insert it.
Should it not be able to inline almost any function if asked to?




Just had another idea..
A function would know statically whether it has been inlined or not. If inlined
it could choose to propagate this attribute to any of its own callees. Not sure
it would be useful though, just thinking aloud..
Feb 11 2011
parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 02/11/11 14:26, Jim wrote:

 Jim Wrote:
 

 bearophile Wrote:

 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).




 If forced inlining is to be supported I think it would be good idea to also
let the _caller_ decide whether to inline a function. The compiler could simply
find the function definition, perhaps parameterize it, and then insert it.
Should it not be able to inline almost any function if asked to?



 
 Just had another idea..
 A function would know statically whether it has been inlined or not. If
inlined it could choose to propagate this attribute to any of its own callees.
Not sure it would be useful though, just thinking aloud..



And at this point what once seemed a simple thing starts to show its
complexity teeth.  Suddenly there are all this adjunct features to be
provided in order to make it properly useful.

Don't get me wrong, I'd actually like having all this... but I'm not
sure of the cost in compiler complexity (and likely slowdown) and
language bloat.

But, here's some notions:

== I really want foo() to be inlined, if even remotely possible! ==

pragma( inline )
int foo () { ... }

== I'll be calling foo(), and I'd like it inlined if possible ==

int bar () {
  pragma( inline, foo );
  // ...
  auto x = foo();
}

== I'm foo(), and I'd like to know if I am being inlined ==

int foo () {
  pragma( inline, true ) {
    // inline code
  }
  pragma( inline, false ) {
    // ordinary code
  }
}

-- or if we ever get that 'meta' namespace some of us want --

int foo () {
  static if ( meta.inlined ) {
    // inline code
  }
  else {
    // ordinary code
  }
}

My chief complaint with my own notions is that 'pragma(inline' ends up
with three different forms.  This just isn't typical of a pragma.

-- Chris N-S
Feb 11 2011
next sibling parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
 
 All of this is hardly related to the simple feature I initially asked for:
 
     string escString (string s)  tellmeifnotinlined {
         s2 = s.replace("\n","\\n");
         s2 = s.replace("\t","\\t");
             return s2;
         }
     void show (X x) {
         // ... use escString ...
         }
 ==>
     Warning: function 'escString' in module 'foo' (line 123) was not
 inlined.
     (or else it was actually inlined)
 
 Which (I guess) is not that a big deal since the compiler needs to
 decide anyway. I just wish to be informed of the result of the decision
 procedure, only in case of 'no'.
 
 Denis



I could really go for that, myself.  Occasionally I've wanted such a
beasty.  I really do think it makes more sense as a pragma() than an
attribute unto itself, though.

-- Chris N-S
Feb 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/12/2011 10:46 AM, Christopher Nicholson-Sauls wrote:

 All of this is hardly related to the simple feature I initially asked for:

      string escString (string s)  tellmeifnotinlined {
          s2 = s.replace("\n","\\n");
          s2 = s.replace("\t","\\t");
              return s2;
          }
      void show (X x) {
          // ... use escString ...
          }
 ==>
      Warning: function 'escString' in module 'foo' (line 123) was not
 inlined.
      (or else it was actually inlined)

 Which (I guess) is not that a big deal since the compiler needs to
 decide anyway. I just wish to be informed of the result of the decision
 procedure, only in case of 'no'.

 Denis



 I could really go for that, myself.  Occasionally I've wanted such a
 beasty.  I really do think it makes more sense as a pragma() than an
 attribute unto itself, though.



Agreed, since it's not a language feature properly speaking. Anyway...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 12 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jim:


 If forced inlining is to be supported



spir was asking for a list of functions that the compiled has inlined, not for
a forced inlining functionality.

Bye,
bearophile
Feb 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 07:08 PM, bearophile wrote:

 Jim:


 I rarely need to go that low-level.



 Two times I have had D1 code that was too much slow compared to equivalent C
code. After profiling and some changes I have understood that the cause was an
important missing inline. With a list of the inlined functions (as done by
CommonLisp some compilers, see the enhancement request in Bugzilla), this
search becomes quicker.



 My hope is that the compiler will sort this out in the end. Give it some time,
or effort to have these optimizations implemented in the compiler.



 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).



To me the relevant aspect is not that much practical effect, but understanding 
how/why/what is inlined by (hopefully good) compilers. Learning about that, 
even if not much put in practice (I don't intend to write the next big 
language's compiler ;-) can only improve coding skills and, say... help and 
stop shooting in the dark.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 09:49 PM, bearophile wrote:

 Jim:


 If forced inlining is to be supported



 spir was asking for a list of functions that the compiled has inlined, not for
a forced inlining functionality.



You are (nearly) right, Bearophile. More precisely, I rather wish  inline on a 
given func to output a compiler message if said func is *not* inlined, due to 
some criterion the compiler uses to decide; at best, some hint about said 
criterion.
I certainly do /not/ ask for forced inlining. (But others take the thread and 
speak of what they wish...)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 10:22 PM, Christopher Nicholson-Sauls wrote:

 On 02/11/11 14:26, Jim wrote:

 Jim Wrote:


 bearophile Wrote:

 The LLVM back-end of LDC is able to inline much more, but even here a list of
inlined/not inlined functions helps. D is almost a system language, so
sometimes you need to go lower level (or you just need a program that's not too
much slow).




 If forced inlining is to be supported I think it would be good idea to also
let the _caller_ decide whether to inline a function. The compiler could simply
find the function definition, perhaps parameterize it, and then insert it.
Should it not be able to inline almost any function if asked to?




 Just had another idea..
 A function would know statically whether it has been inlined or not. If
inlined it could choose to propagate this attribute to any of its own callees.
Not sure it would be useful though, just thinking aloud..



 And at this point what once seemed a simple thing starts to show its
 complexity teeth.  Suddenly there are all this adjunct features to be
 provided in order to make it properly useful.

 Don't get me wrong, I'd actually like having all this... but I'm not
 sure of the cost in compiler complexity (and likely slowdown) and
 language bloat.

 But, here's some notions:

 == I really want foo() to be inlined, if even remotely possible! ==

 pragma( inline )
 int foo () { ... }

 == I'll be calling foo(), and I'd like it inlined if possible ==

 int bar () {
    pragma( inline, foo );
    // ...
    auto x = foo();
 }

 == I'm foo(), and I'd like to know if I am being inlined ==

 int foo () {
    pragma( inline, true ) {
      // inline code
    }
    pragma( inline, false ) {
      // ordinary code
    }
 }

 -- or if we ever get that 'meta' namespace some of us want --

 int foo () {
    static if ( meta.inlined ) {
      // inline code
    }
    else {
      // ordinary code
    }
 }

 My chief complaint with my own notions is that 'pragma(inline' ends up
 with three different forms.  This just isn't typical of a pragma.

 -- Chris N-S



All of this is hardly related to the simple feature I initially asked for:

	string escString (string s)  tellmeifnotinlined {
	    s2 = s.replace("\n","\\n");
	    s2 = s.replace("\t","\\t");
             return s2;
         }
	void show (X x) {
	    // ... use escString ...
         }
==>
	Warning: function 'escString' in module 'foo' (line 123) was not inlined.
	(or else it was actually inlined)

Which (I guess) is not that a big deal since the compiler needs to decide 
anyway. I just wish to be informed of the result of the decision procedure, 
only in case of 'no'.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
prev sibling parent so <so so.so> writes:
 All of this is hardly related to the simple feature I initially asked  
 for:

 	string escString (string s)  tellmeifnotinlined {
 	    s2 = s.replace("\n","\\n");
 	    s2 = s.replace("\t","\\t");
              return s2;
          }
 	void show (X x) {
 	    // ... use escString ...
          }
 ==>
 	Warning: function 'escString' in module 'foo' (line 123) was not  
 inlined.
 	(or else it was actually inlined)

 Which (I guess) is not that a big deal since the compiler needs to  
 decide anyway. I just wish to be informed of the result of the decision  
 procedure, only in case of 'no'.

 Denis



Guys, i don't know what are you trying or why you simply seem to avoid my  
reasoning on this, if you don't need this (and you all seem not use it)  
why are you trying to find solutions for the problems that doesn't affect  
you directly? :)

Unline a few of you said this is not a complex problem and actually it  
hasn't been complex in C++ either for again, practical purposes.

Standard C++ says:
For class/struct methods, compiler inlines things and it is aware of most  
of them wrappers so you don't need "inline" keyword there.
But still it does have this keyword as a hint to use other methods. This  
has never been enough and all major compilers now have forced inlines.  
(always_inline, __forceinline...)
What they do is forcing to compiler inline a function and if compiler  
won't do it it issues an error to state why.

All is needed is just i said in another post:
 inline // inline or issue and error why you won't.

- simple
- serves practical purposes rather than fiction
- it does no harm to anyone
- so easy to implement
- it is sometimes advanced but still something controllable

Now please what is wrong here someone enlighten me.

Thanks.
Feb 11 2011