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

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.

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

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.

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

:)

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

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

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