Walter Bright wrote:
> Jeremie Pelletier wrote:
>> Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax.
> 
> The thing about const is it only specifies a read only view of an object, it does *not* specify that the referenced object will not change. That is why pass by value cannot be "optimized" to be pass by reference.
> 

To elaborate on this, consider this case:

import std.stdio;

struct X { int v; }

void test(X x, void delegate() dg) { writefln(x.v); dg(); writefln(x.v); }

void main() {
  X ecks;
  test(ecks, { ecks.v = 17; });
}

downs Wrote:

> Walter Bright wrote:
> > Jeremie Pelletier wrote:
> >> Isn't it possible to make 'const ref S' or 'in S' generate the same machine code as 'in S*'? To me it would seem the semantics of the two are the same, with 'const S*' being useful syntax for C compatibility while 'in S' and 'const ref S' are both D syntax.
> > 
> > The thing about const is it only specifies a read only view of an object, it does *not* specify that the referenced object will not change. That is why pass by value cannot be "optimized" to be pass by reference.
> > 
> 
> To elaborate on this, consider this case:
> 
> import std.stdio;
> 
> struct X { int v; }
> 
> void test(X x, void delegate() dg) { writefln(x.v); dg(); writefln(x.v); }
> 
> void main() {
>   X ecks;
>   test(ecks, { ecks.v = 17; });
> }

Ok, I understand why it cant be done for 'in S' but I don't see why 'const ref S' cannot have the same semantics as 'in S*', unless 'ref' doesn't mean that the struct is implicitly dereferenced.

Here is some code to illustrate my point of view:

struct S { int i; }
S s;

void Stuff() { s.i++; }

void Foo(in S* s) {
    writefln(s.i);
    Stuff();
    writefln(s.i);
}
void Bar(const ref S s) {
    writefln(s.i);
    Stuff();
    writefln(s.i);
}

int main() {
    // Those both do the exact same thing
    Foo(&s);
    Bar(s);
}

If they are meant to have different semantics, then when is a good time to use ref? It would seem to me 'in S*' and 'S*' carry both behaviors you want in a referenced parameter: const and mutable. In any case only the reference is passed by value, not the struct itself.

If the method calls another method which modifies the const view on the reference, then it should be a logic error from the programmer (good old shooting yourself in the foot) without the compiler getting in the way. Making fool-proof language semantics is a good idea, but IMO it shouldn't impact performance, or else any bit of code looking for time critical performance will never use the syntax that makes D shine, and a lot of confusion will spread around as both types of syntax are used. It also makes it confusing to interface with IDL.

Alls I'm suggesting is that 'const ref S' and 'ref S' generate the same machine code as 'in S*' and 'S*', which would prevent us from using different syntax to get the performance boost, when in the end the intended behavior is the same.

On Thu, Aug 27, 2009 at 8:17 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jeremie Pelletier wrote:
>>
>> Isn't there a way to implement RVO to work on parameters (PVO?) too
>> if the storage is const?
>
> No, and it doesn't work for C++ either. Consider:
>

You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?

Jarrett Billingsley wrote:
> You're addressing the 'const' issue, but you haven't addressed the
> OP's issue: that 'ref', for whatever reason, prevents inlining. Const
> aside, why is this so?

Because I never updated the inlining code to handle it.

On Fri, Aug 28, 2009 at 4:20 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?
>
> Because I never updated the inlining code to handle it.

Well I'm glad it's that simple, and I'm sure Jeremie is too ;)

Jarrett Billingsley wrote:
> On Fri, Aug 28, 2009 at 4:20 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> Jarrett Billingsley wrote:
>>> You're addressing the 'const' issue, but you haven't addressed the
>>> OP's issue: that 'ref', for whatever reason, prevents inlining. Const
>>> aside, why is this so?
>> Because I never updated the inlining code to handle it.
> 
> Well I'm glad it's that simple, and I'm sure Jeremie is too ;)

There are a lot of D specific optimization opportunities that are left undone for now.

On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?
>
> Because I never updated the inlining code to handle it.

Wow.  That's it?  So let's get it done already!  This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed.   It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code.  If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion.

--bb

On Fri, 28 Aug 2009, Bill Baxter wrote:

> On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> > Jarrett Billingsley wrote:
> >>
> >> You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?
> >
> > Because I never updated the inlining code to handle it.
> 
> Wow.  That's it?  So let's get it done already!  This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed.   It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code.  If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion.
> 
> --bb

Ok.. so we should expect a patch from you sometime soon?  You did include yourself in the 'us' inside "let's", right?

Walter Bright escribió:
> Jarrett Billingsley wrote:
>> On Fri, Aug 28, 2009 at 4:20 PM, Walter
>> Bright<newshound1@digitalmars.com> wrote:
>>> Jarrett Billingsley wrote:
>>>> You're addressing the 'const' issue, but you haven't addressed the
>>>> OP's issue: that 'ref', for whatever reason, prevents inlining. Const
>>>> aside, why is this so?
>>> Because I never updated the inlining code to handle it.
>>
>> Well I'm glad it's that simple, and I'm sure Jeremie is too ;)
> 
> There are a lot of D specific optimization opportunities that are left undone for now.

Why?

Seeing D as "a systems language with features form high-level languages but without the performance penalty so you can prefer it over C/C++/Java/C# etc.", if D's performance isn't that good then there's not much competition for people coming from either sides that expect high performance.

bearophile and others from time to time complain about performance issues in D, just because D promises performance. I think this is more important that adding more features that won't give you higher performance.

performance

(sorry, had to repeat that word one more time :-P)

On Fri, Aug 28, 2009 at 3:21 PM, Brad Roberts<braddr@puremagic.com> wrote:
> On Fri, 28 Aug 2009, Bill Baxter wrote:
>
>> On Fri, Aug 28, 2009 at 1:20 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>> > Jarrett Billingsley wrote:
>> >>
>> >> You're addressing the 'const' issue, but you haven't addressed the OP's issue: that 'ref', for whatever reason, prevents inlining. Const aside, why is this so?
>> >
>> > Because I never updated the inlining code to handle it.
>>
>> Wow.  That's it?  So let's get it done already!  This is really a shame to have this hanging around in a language whose biggest selling point over the competition is speed.   It's been shown many times that DMD's failure to inline ref args has significant impact (~10%) on the performance of numerical code.  If you can easily give these kinds of code a 10% boost without too much effort then that's a big win in my opinion.
>>
>> --bb
>
> Ok.. so we should expect a patch from you sometime soon?  You did include yourself in the 'us' inside "let's", right?

I'm actually surprised Don hasn't jumped on this one, given that it's primarily numerical code that it seems to be affecting.   If I were still at my old job using D heavily,  I would probably take a whack at fixing this one, just because it has been such an annoyance to me.   I put up with it figuring it would be fixed someday, and I assumed there must be something tricky about it or else it would have been done already.  But given Walter's answer just now, it sounds like a quick fix for him or someone else familiar with the compilers internals.

--bb