• bobef <bobef nosmap-abv.bg> Jul 17 2008
• dsimcha <dsimcha yahoo.com> Jul 17 2008
• bearophile <bearophileHUGS lycos.com> Jul 17 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Jul 17 2008
• "Nick Sabalausky" <a a.a> Jul 17 2008
• JAnderson <ask me.com> Jul 18 2008
• Bill Baxter <dnewsgroup billbaxter.com> Jul 17 2008
• Jason House <jason.james.house gmail.com> Jul 17 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 17 2008
• Walter Bright <newshound1 digitalmars.com> Jul 17 2008
• Extrawurst <spam extrawurst.org> Jul 18 2008
• Walter Bright <newshound1 digitalmars.com> Jul 18 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 18 2008
• Matti Niemenmaa <see_signature for.real.address> Jul 18 2008
• superdan <super dan.org> Jul 18 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jul 18 2008
• BCS <ao pathlink.com> Jul 18 2008
• Matti Niemenmaa <see_signature for.real.address> Jul 18 2008
• Walter Bright <newshound1 digitalmars.com> Jul 18 2008
• JAnderson <ask me.com> Jul 17 2008
• JAnderson <ask me.com> Jul 18 2008
• Don <nospam nospam.com.au> Jul 18 2008
• superdan <super dan.org> Jul 18 2008
• JAnderson <ask me.com> Jul 18 2008

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

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.

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

"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 

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

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

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

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.

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

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?

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?

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.

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

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

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.

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

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

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

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.
 

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

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

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.

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

:)

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