www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inlining

reply bobef <bobef nosmap-abv.bg> writes:
This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

Regards, bobef
Jul 17 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
If we're going to make the jump and expose these features to the programmer, a
noinline attribute to do the opposite might be nice also.  Here's a hypothetical
example of where that might be nice:

void myFunc(int foo) {
   foreach(i, 0..1_000_000) {
       if(foo < 5) {  //This is an unusual case, foo usually >5.
          bar(foo);
       }
       //Stuff that may change the value of foo.
   }
   //More stuff that may change the value of foo.
   foreach(i; 0..1_000_000) {
       if(foo < 5) {  //Again unusual
           bar(foo);
       }
       //More stuff that may change the value of foo.
   }
}

In this case the compiler, not understanding the high-level meaning of what is
being done, would likely not realize that foo is almost always >= 5 in
real-world
scenarios.  It would likely inline bar at both places it's called from,
contributing to code bloat, especially since it's called from a loop that
iterates
a lot of times.  However, since the programmer knows that the branch that calls
bar() will be taken very infrequently, the programmer might want to specify that
bar() should not be inlined.
Jul 17 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:
 In this case the compiler, not understanding the high-level meaning of what is
 being done, would likely not realize that foo is almost always >= 5 in
real-world
 scenarios.

GCC has profile-guided optimization, that is often enough for the compiler to know what branch is the most frequent. In GCC there's the __builtin_expect() too for a similar purpose (if a branch calls a function rarely, the compiler understands it's probably not positive to inline it). Bye, bearophile
Jul 17 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

Although a noinline directive would be ideal, it is technically possible to force non-inlining of functions by using D interface files (.di) to define the functions as prototypes, and only compile the real code in an object file. But that's a lot of work compared to just tagging the function. Forcing inlining, on the other hand, is impossible currently. -Steve
Jul 17 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:g5p23e$2iue$1 digitalmars.com...
 "dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

Although a noinline directive would be ideal, it is technically possible to force non-inlining of functions by using D interface files (.di) to define the functions as prototypes, and only compile the real code in an object file. But that's a lot of work compared to just tagging the function. Forcing inlining, on the other hand, is impossible currently. -Steve

You could write it as a string mixin.
Jul 17 2008
parent JAnderson <ask me.com> writes:
Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:g5p23e$2iue$1 digitalmars.com...
 "dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

to force non-inlining of functions by using D interface files (.di) to define the functions as prototypes, and only compile the real code in an object file. But that's a lot of work compared to just tagging the function. Forcing inlining, on the other hand, is impossible currently. -Steve

You could write it as a string mixin.

What about using a template? Wouldn't that encourage the compiler to inline? -Joel
Jul 18 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

Looking ahead, I think macro() will reduce the need for an inline specifier. Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it. --bb
Jul 17 2008
next sibling parent Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:

 bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

Looking ahead, I think macro() will reduce the need for an inline specifier. Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it. --bb

The last thing I want from a language is two completely different methods that may require me to flip implementation methods for assumed gains from compiler optimizations.
Jul 17 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g5od1q$2v3b$3 digitalmars.com...
 bobef wrote:
 This has probably been asked many times before. If someone knows of such 
 discussion please paste me a link. Why not an 'inline' attribute? We all 
 know that the compiler can be stupid some times, and even if it is not 
 people may want to inline something that is normally not appropriate for 
 inlining. Auto inlining is fine, but people should have control over such 
 kind of things I believe.

Looking ahead, I think macro() will reduce the need for an inline specifier. Yeh, it won't be quite the same, but it'll be close enough that making a separate inline keyword may not be worth it. --bb

Macros aren't coming until D3.
Jul 17 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.

I don't see the need for an inline or non-inline specifier. It's as obsolete as the register keyword. Does anyone have a non-trivial non-contrived benchmark where a difference is measurable?
Jul 17 2008
next sibling parent reply Extrawurst <spam extrawurst.org> writes:
All i can say is, that over at work when profiling our 3D Game Engine, 
it is often the case that forcing the compiler to inline (MSVC 2005) 
helps making peaces of code faster.


Walter Bright schrieb:
 Bill Baxter wrote:
 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.

I don't see the need for an inline or non-inline specifier. It's as obsolete as the register keyword. Does anyone have a non-trivial non-contrived benchmark where a difference is measurable?

Jul 18 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:
 All i can say is, that over at work when profiling our 3D Game Engine, 
 it is often the case that forcing the compiler to inline (MSVC 2005) 
 helps making peaces of code faster.

The -inline switch to the compiler will inline functions.
Jul 18 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g5qnt3$227v$1 digitalmars.com...
 Extrawurst wrote:
 All i can say is, that over at work when profiling our 3D Game Engine, it 
 is often the case that forcing the compiler to inline (MSVC 2005) helps 
 making peaces of code faster.

The -inline switch to the compiler will inline functions.

Walter, I think he's _well aware_ of that. He's talking about forcing inlining, regardless of what the compiler thinks is best.
Jul 18 2008
prev sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as 
 obsolete as the register keyword.

Then why was "inout" renamed to "ref"? Before you say, "so that we could have 'const ref'", let me note that ref in that sense is as obsolete as inline or register. It should just be "in" or the default and the compiler should figure out whether it's by-reference or by-value. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Jul 18 2008
parent reply superdan <super dan.org> writes:
Matti Niemenmaa Wrote:

 Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as 
 obsolete as the register keyword.

Then why was "inout" renamed to "ref"? Before you say, "so that we could have 'const ref'", let me note that ref in that sense is as obsolete as inline or register. It should just be "in" or the default and the compiler should figure out whether it's by-reference or by-value.

how is that even close to making sense? before you say, "but value vs. 'in' is entirely transparent to the user", let me note that aliasing is going to fuck that plan right there. deciding value vs. reference only works for invariant shit. it's in fact part of why invariant shit is so fucking brilliant.
Jul 18 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"superdan" <super dan.org> wrote in message 
news:g5qa4f$n1g$1 digitalmars.com...
 Matti Niemenmaa Wrote:

 Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as
 obsolete as the register keyword.

Then why was "inout" renamed to "ref"? Before you say, "so that we could have 'const ref'", let me note that ref in that sense is as obsolete as inline or register. It should just be "in" or the default and the compiler should figure out whether it's by-reference or by-value.

how is that even close to making sense? before you say, "but value vs. 'in' is entirely transparent to the user", let me note that aliasing is going to fuck that plan right there. deciding value vs. reference only works for invariant shit. it's in fact part of why invariant shit is so fucking brilliant.

Dan, you make good points and seem to have a head on your shoulders, but the swearing really is unnecessary. That doesn't mean I don't swear, I do it all the time. But this is not really the place for it. Consider how much more coherent and reasonable your post sounds like this: ---- how is that even close to making sense? before you say, "but value vs. 'in' is entirely transparent to the user", let me note that aliasing is going to completely invalidate that plan right there. deciding value vs. reference only works for invariant data. it's in fact part of why invariant data is so incredibly brilliant. ---- Please don't take this as an attack, I'm not trying to make you feel like you're less of a member of the community. Swearing on the internet just makes you seem like a 13-year-old boy.
Jul 18 2008
parent BCS <ao pathlink.com> writes:
Reply to Jarrett,

 Swearing on the
 internet just makes you seem like a 13-year-old boy.
 

tactful and well put On the Internet often the /only/ available view of a person is what they type. As I often quit reading after the 2nd or 3rd cuss word, it's easy to never see anything inelegant that might be written later (and I don't consider this a problem).
Jul 18 2008
prev sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
superdan wrote:
 before you say, "but value vs. 'in' is entirely transparent to the user", let
 me note that aliasing is going to fuck that plan right there.
 
 deciding value vs. reference only works for invariant shit. it's in fact part
 of why invariant shit is so fucking brilliant.

If it's a const reference, aliasing doesn't matter, no? Or am I missing something about D2's latest const system (quite possible)? One should only be reading from a const ref so it's semantically equivalent to just 'in'. 'inout' should still be there, with reasonable aliasing restrictions. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Jul 18 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Matti Niemenmaa wrote:
 superdan wrote:
 before you say, "but value vs. 'in' is entirely transparent to the 
 user", let
 me note that aliasing is going to fuck that plan right there.

 deciding value vs. reference only works for invariant shit. it's in 
 fact part
 of why invariant shit is so fucking brilliant.

If it's a const reference, aliasing doesn't matter, no? Or am I missing something about D2's latest const system (quite possible)? One should only be reading from a const ref so it's semantically equivalent to just 'in'.

It would have to be an invariant ref, not a const ref, for aliasing to not matter.
 
 'inout' should still be there, with reasonable aliasing restrictions.
 

Jul 18 2008
prev sibling parent reply JAnderson <ask me.com> writes:
bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.
 
 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better handle on when to inline. There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer. But that's C++. D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice. -Joel
Jul 17 2008
parent reply JAnderson <ask me.com> writes:
JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' attribute? 
 We all know that the compiler can be stupid some times, and even if it 
 is not people may want to inline something that is normally not 
 appropriate for inlining. Auto inlining is fine, but people should 
 have control over such kind of things I believe.

 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better handle on when to inline. There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer. But that's C++. D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice. -Joel

I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow. So I placed a few inlines around and *bam* that code started running faster. Then I profiled the code as a whole to see how much of an improvement I'd gained. However the game was actually running slower. It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time. I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse. -Joel
Jul 18 2008
parent reply Don <nospam nospam.com.au> writes:
JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better handle on when to inline. There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer. But that's C++. D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice. -Joel

I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow. So I placed a few inlines around and *bam* that code started running faster. Then I profiled the code as a whole to see how much of an improvement I'd gained. However the game was actually running slower. It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time. I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse. -Joel

Yup. Code cache can easily become a bottleneck. Similarly, turning on 'optimise for speed' for a whole program is almost always a bad idea. More useful than 'inline', would be some way to tell the compiler 'this function is speed-critical'. If nothing else, it would have some documentation value.
Jul 18 2008
next sibling parent superdan <super dan.org> writes:
Don Wrote:

 JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better handle on when to inline. There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer. But that's C++. D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice. -Joel

I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow. So I placed a few inlines around and *bam* that code started running faster. Then I profiled the code as a whole to see how much of an improvement I'd gained. However the game was actually running slower. It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time. I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse. -Joel

Yup. Code cache can easily become a bottleneck. Similarly, turning on 'optimise for speed' for a whole program is almost always a bad idea. More useful than 'inline', would be some way to tell the compiler 'this function is speed-critical'. If nothing else, it would have some documentation value.

just use the 'super' keyword: void myfunc() super { } :)
Jul 18 2008
prev sibling parent JAnderson <ask me.com> writes:
Don wrote:
 JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better handle on when to inline. There have been some studies (does anyone have the links to these) where they've shown that most of the time the compiler can make a more intelligent guess then the average engineer. But that's C++. D does this automatic virtual's thing so its difficult to say whether the compiler can always make a good choice. -Joel

I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow. So I placed a few inlines around and *bam* that code started running faster. Then I profiled the code as a whole to see how much of an improvement I'd gained. However the game was actually running slower. It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time. I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse. -Joel

Yup. Code cache can easily become a bottleneck. Similarly, turning on 'optimise for speed' for a whole program is almost always a bad idea.

I've had some good results with whole program optimisation. However not always.
 
 More useful than 'inline', would be some way to tell the compiler 'this 
 function is speed-critical'. If nothing else, it would have some 
 documentation value.

I think that's a good idea. The compiler could also spin more cycles to optimize that piece of code. -Joel
Jul 18 2008