www.digitalmars.com         C & C++   DMDScript  

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

reply Jim <bitcirkel yahoo.com> writes:
spir Wrote:


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




Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
Why do you need information if you can't affect the outcome?

bearophile Wrote:

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



And it's true. To fit that niche you need control. D proudly supports inline
assembler, after all... Why not function inlining?


Also, the meta-namespace is intriguing:

   static if( meta.inlined )
   {
      ...
   }

A function would know statically whether it was inlined, perhaps on request by
the caller of the function.

The meta-namespace could provide a lot of useful information.
Feb 12 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



I want to know it. First, because it's valuable information in and by itself. 
Second, because it teaches me something. Third, because I can then possibly 
decide to not factor out (may be wrong, but still, I can measure...).
Glasnost for compilers! ;-)

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


 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself. 
 Second, because it teaches me something. Third, because I can then possibly 
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)



Glasnost! :)

How about the meta-namespace then:

static if( meta.inlined )
{
   writeln("got it!");
}
Feb 12 2011
parent reply ivan <pavlov pavlov.org> writes:
Jim Wrote:


 spir Wrote:
 

 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself. 
 Second, because it teaches me something. Third, because I can then possibly 
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)



 Glasnost! :)
 
 How about the meta-namespace then:
 
 static if( meta.inlined )
 {
    writeln("got it!");
 }
 



Why not:

void foo() { printf("da\n"); }

const bool bar =  glasnost.inlined(foo);

or

const bool bar = __glasnost << inlined!foo;
Feb 12 2011
next sibling parent ivan <pavlov pavlov.org> writes:
ivan Wrote:


 Jim Wrote:
 

 spir Wrote:
 

 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself. 
 Second, because it teaches me something. Third, because I can then possibly 
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)



 Glasnost! :)
 
 How about the meta-namespace then:
 
 static if( meta.inlined )
 {
    writeln("got it!");
 }
 



 Why not:
 
 void foo() { printf("da\n"); }
 
 const bool bar =  glasnost.inlined(foo);
 
 or
 
 const bool bar = __glasnost << inlined!foo;
 



In general we need traits for discovering all optimizations:

pragma(msg, __traits.optimizations.tupleof(foo).stringof);

// results as an example in: ("loop unfolding", "sse2 multiplication",
"inline-strong-pass", "tail-call optimization")
Feb 12 2011
prev sibling parent Jim <bitcirkel yahoo.com> writes:
ivan Wrote:


 Jim Wrote:
 

 spir Wrote:
 

 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself. 
 Second, because it teaches me something. Third, because I can then possibly 
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)



 Glasnost! :)
 
 How about the meta-namespace then:
 
 static if( meta.inlined )
 {
    writeln("got it!");
 }
 



 Why not:
 
 void foo() { printf("da\n"); }
 
 const bool bar =  glasnost.inlined(foo);
 
 or
 
 const bool bar = __glasnost << inlined!foo;
 




Ideally, you also want to be able to request inlining at the place of calling a
function, not only at the definition of the function.
Feb 12 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/12/2011 12:42 PM, Jim wrote:

 spir Wrote:


 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline is
certainly a verb -- even imperative mood, so not just asking for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself.
 Second, because it teaches me something. Third, because I can then possibly
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)



 Glasnost! :)

 How about the meta-namespace then:

 static if( meta.inlined )
 {
     writeln("got it!");
 }



I vote +++ for the idea of meta in general. (And tons of + for real type 
objects as plain D data structures).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/13/2011 04:13 AM, so wrote:

 On Sat, 12 Feb 2011 13:20:36 +0200, spir <denis.spir gmail.com> wrote:


 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  inline
 is certainly a verb -- even imperative mood, so not just asking for
 information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by itself.
 Second, because it teaches me something. Third, because I can then possibly
 decide to not factor out (may be wrong, but still, I can measure...).
 Glasnost for compilers! ;-)

 Denis



 This is to all of you. Inlining is not a toy, knowing if a function is inlined
 or not has no practical purposes in the sense you are asking, or any other for
 that matter.
 This is a low level optimization, again it is not a toy to play with, and D
 being a system language (where function call is cheap) makes this even more
 meaningless.



How many times do I need to repeat I do not want to force inlining? Or what 
else are you talking about?

Instead, I want to /know/. Example use: ensure trivial externalisation dist 
below will be properly inlined back by the compiler. I factorise out dist for 
code clarity, but do not want this to cause stupid performance penalty. Cases:
* the compiler shut up --> ok
* the compiler says 'no' -- possibly 'because ...'
     ~ I can decide to unfactor out
     ~ I can measure, and realise cost of func call is nothing compared to 
square root
     ~ I may learn something from additional info
     ~ I may realise the case is not as trivial as it seems
     ~ I may learn about highering chances of inlining

// billions of them
struct Point {
     float x,y;
     float d;
     this (float x, float x) {
         this.x = x;
         this.y = y;
         // inline or not inline?
         this.d = dist(x,y);
pragma (inlineinfo) {
     static float dist (int x, int y) {
         return squareRoot(x*x + y*y);
     }
}
}

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 12 2011
prev sibling next sibling parent so <so so.so> writes:
On Sat, 12 Feb 2011 13:20:36 +0200, spir <denis.spir gmail.com> wrote:


 On 02/12/2011 12:15 PM, Jim wrote:

 Sorry about that, but I think that is a closely related discussion.  
  inline is certainly a verb -- even imperative mood, so not just asking  
 for information.
 Why do you need information if you can't affect the outcome?



 I want to know it. First, because it's valuable information in and by  
 itself. Second, because it teaches me something. Third, because I can  
 then possibly decide to not factor out (may be wrong, but still, I can  
 measure...).
 Glasnost for compilers! ;-)

 Denis



This is to all of you. Inlining is not a toy, knowing if a function is  
inlined or not has no practical purposes in the sense you are asking, or  
any other for that matter.
This is a low level optimization, again it is not a toy to play with, and  
D being a system language (where function call is cheap) makes this even  
more meaningless.

Now i am repeating this the third time seem people just ignore it:

. Inlining problem in D has never been about determining a function is  
inlined or not. Walter 100% right on this, go check the freaking asm  
output.
. The problem is that we have "no" say in the decision process, and this  
is a serious matter in some high performance areas, serious that goes to  
decide if they will use a language or not.

So please lets focus on the problem and not waste the time on irrelevant  
things/changes/decisions.
Feb 12 2011
prev sibling next sibling parent so <so so.so> writes:
 How many times do I need to repeat I do not want to force inlining? Or  
 what else are you talking about?



And this is why it doesn't make sense.
What are we doing here? Are we trying to find practical solutions to real  
world problems or just showing how useless things D can do?


 Instead, I want to /know/. Example use: ensure trivial externalisation  
 dist below will be properly inlined back by the compiler. I factorise  
 out dist for code clarity, but do not want this to cause stupid  
 performance penalty. Cases:
 * the compiler shut up --> ok
 * the compiler says 'no' -- possibly 'because ...'
      ~ I can decide to unfactor out
      ~ I can measure, and realise cost of func call is nothing compared  
 to square root



Listen, inlining is not something to play with like that, you either want  
a function to be inlined or not, this simple.
The reasons are straightforward. Say you have an intersection test where  
you optimized and such, it might contain square roots, dots, crosses  
whatever and nothing you can do about it anymore.
It is obviously costly, costs far more than the function call cost. So  
far, everything as usual, compiler free to do what it believes right. But  
you know beforehand this block of code will run in many loops which  
changes the scenario, now function call is an issue. You don't care if  
compiler did it or not, you simply want it to be done.


      ~ I may learn something from additional info



Which will serve no purpose!


      ~ I may realise the case is not as trivial as it seems



Which again surves no purpose unlike you want it to be done.


 // billions of them
 struct Point {
      float x,y;
      float d;
      this (float x, float x) {
          this.x = x;
          this.y = y;
          // inline or not inline?
          this.d = dist(x,y);
 pragma (inlineinfo) {
      static float dist (int x, int y) {
          return squareRoot(x*x + y*y);
      }
 }
 }



If in your program flow,
. this struct is to be used frequently
. performance is your primary concern,
. you have no other things to worry about (algorithms, other optimizations)
. you know if inlining is a gain.

Then you know beforehand that function should be inlined or not, otherwise  
knowing that has no purpose whatsoever.
Feb 12 2011
prev sibling next sibling parent so <so so.so> writes:
Ok i stop, looks like i fail to make my point to anyone :)
Feb 12 2011
prev sibling parent piotrek <starpit tlen.pl> writes:
On Sun, 13 Feb 2011 09:57:52 +0200, so wrote:


 Ok i stop, looks like i fail to make my point to anyone :)



I see your point and I agree with you.

Cheers
Piotrek
Feb 14 2011