www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About ref used for performance reasons with struct

reply "deadalnix" <deadalnix gmail.com> writes:
Ok, We have 2 usages of ref : when you actually need to modify 
informations, and for performance reasons. Let's talk about the 
second one.

Passing by ref to improve performance is not ideal. First this is 
quite hard to know when it is actually faster to pass by ref and 
to pass by value, especially in generic code. Secondly it is easy 
to forget to use ref at some location, and a lot of small 
performance improvement are lost in the process. Finally, this 
may be error prone.

I'm thinking about it for a while now and I'm now convinced that 
we should allow the compiler to do that job for us. Let me 
explain.

When a function accept a struct, the compiler is free to use that 
function, or an altered one taking a reference as parameter. Here 
are some rules the compiler can use to know which one to call 
from callee side :

The caller is free to call the ref version of the function unless 
(rules evaluate in order) :
  - The argument is an rvalue (in such case, no postblit is 
executed as well).
  - The argument is shared.
  - The argument's postblit in not pure (weakly).

The callee isn't modified for the vanilla function, but must 
create a local copy of the argument in the following reasons in 
the ref version :
  - The argument is binded to a mutable ref.(even as hidden 
argument as for member method).
  - The argument is actually modified.
  - address of anything coming from the struct is taken.

The compiler is free to apply such treatment only in a branch of 
the callee, ie :

// Compiler choose to create an alternative ref version for 
performance.
void foo(MyStruct s) {
     if(condition) {
         // Operation require a copy to not alter what the caller 
see.
         // A s is copied on stack and postblit is called.
         s.field = 5;
     } else {
         // No operation requiring local copy is performed.
         // No local copy is created.
     }
}

The compiler is however disallowed to create multiple copies in 
the callee. If several branches requires it, then the copy have 
to be made in a common branch.

Note that the compiler don't HAVE to do this, but is allowed to. 
Modifying the spec in such way allow the compiler to avoid many 
copies of struct let us get rid of most ref parameters, keeping 
them for what they really are for.
Feb 10 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.

 Passing by ref to improve performance is not ideal. First this 
 is quite hard to know when it is actually faster to pass by ref 
 and to pass by value, especially in generic code. Secondly it 
 is easy to forget to use ref at some location, and a lot of 
 small performance improvement are lost in the process. Finally, 
 this may be error prone.

 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let me 
 explain.

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter. Here are some rules the compiler can use to know 
 which one to call from callee side :

 The caller is free to call the ref version of the function 
 unless (rules evaluate in order) :
  - The argument is an rvalue (in such case, no postblit is 
 executed as well).
  - The argument is shared.
  - The argument's postblit in not pure (weakly).

 The callee isn't modified for the vanilla function, but must 
 create a local copy of the argument in the following reasons in 
 the ref version :
  - The argument is binded to a mutable ref.(even as hidden 
 argument as for member method).
  - The argument is actually modified.
  - address of anything coming from the struct is taken.

 The compiler is free to apply such treatment only in a branch 
 of the callee, ie :

 // Compiler choose to create an alternative ref version for 
 performance.
 void foo(MyStruct s) {
     if(condition) {
         // Operation require a copy to not alter what the 
 caller see.
         // A s is copied on stack and postblit is called.
         s.field = 5;
     } else {
         // No operation requiring local copy is performed.
         // No local copy is created.
     }
 }

 The compiler is however disallowed to create multiple copies in 
 the callee. If several branches requires it, then the copy have 
 to be made in a common branch.

 Note that the compiler don't HAVE to do this, but is allowed 
 to. Modifying the spec in such way allow the compiler to avoid 
 many copies of struct let us get rid of most ref parameters, 
 keeping them for what they really are for.

EDIT: I forgot one condition for the callee, it is disallowed to copy the struct or any part of it that contain reference/pointer is the postblit isn't strongly pure.
Feb 10 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
But what if we want to pass a struct with intent as value?
With this solution, we don't have much control.
In general, I like the idea, but we should mark such parameter
with '&' or whatever, so at least we can still take some 
influence.
Feb 11 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.

 Passing by ref to improve performance is not ideal. First this 
 is quite hard to know when it is actually faster to pass by ref 
 and to pass by value, especially in generic code. Secondly it 
 is easy to forget to use ref at some location, and a lot of 
 small performance improvement are lost in the process. Finally, 
 this may be error prone.

 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let me 
 explain.

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter. Here are some rules the compiler can use to know 
 which one to call from callee side :

 The caller is free to call the ref version of the function 
 unless (rules evaluate in order) :
  - The argument is an rvalue (in such case, no postblit is 
 executed as well).
  - The argument is shared.
  - The argument's postblit in not pure (weakly).

 The callee isn't modified for the vanilla function, but must 
 create a local copy of the argument in the following reasons in 
 the ref version :
  - The argument is binded to a mutable ref.(even as hidden 
 argument as for member method).
  - The argument is actually modified.
  - address of anything coming from the struct is taken.

 The compiler is free to apply such treatment only in a branch 
 of the callee, ie :

 // Compiler choose to create an alternative ref version for 
 performance.
 void foo(MyStruct s) {
     if(condition) {
         // Operation require a copy to not alter what the 
 caller see.
         // A s is copied on stack and postblit is called.
         s.field = 5;
     } else {
         // No operation requiring local copy is performed.
         // No local copy is created.
     }
 }

 The compiler is however disallowed to create multiple copies in 
 the callee. If several branches requires it, then the copy have 
 to be made in a common branch.

 Note that the compiler don't HAVE to do this, but is allowed 
 to. Modifying the spec in such way allow the compiler to avoid 
 many copies of struct let us get rid of most ref parameters, 
 keeping them for what they really are for.

How does this work in the context of modular programming? Does the compiler generate multiple code for each case, to make the code work regardless of what is decided at the call site? Or is the code written in a canonical form inside the module, which gets to be rewritten when all modules are linked into the final binary? By modules I mean the case where you only have a .di file + binary code for the module. For me the right form to distribute libraries. -- Paulo
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 10:04:55 UTC, Namespace wrote:
 But what if we want to pass a struct with intent as value?
 With this solution, we don't have much control.
 In general, I like the idea, but we should mark such parameter
 with '&' or whatever, so at least we can still take some 
 influence.

That is the whole point, everything appear as if it is passed by value. struct A { uint member; this(this) { // Very long but pure operation. } } void main() { A a; foo(a); assert(a.member = 0); // Pass. } void foo(A a) { // Compiler can choose to pass by ref here. bar(a); } void bar(A a) { // If compiler choose to pass by ref, then it is bar responsibility to create a copy. A smarter move from the compiler is to mark bar as non electable for such optimization. a.member = 5; } In the example above, the compiler is allowed to pass a by ref to foo. As a consequence, the very long operation within the postblit can only be executed once, instead of 2.
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 10:21:30 UTC, Paulo Pinto wrote:
 How does this work in the context of modular programming?

 Does the compiler generate multiple code for each case, to make 
 the code work regardless of what is decided at the call site?

 Or is the code written in a canonical form inside the module, 
 which gets to be rewritten when all modules are linked into the 
 final binary?

 By modules I mean the case where you only have a .di file + 
 binary code for the module. For me the right form to distribute 
 libraries.

I think it is reasonable to say that this will not work is the compiler don't have callee's implementation.
Feb 11 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.

I touched on the idea in a StackOverflow answer a while back: http://stackoverflow.com/a/8515844 The meaning of 'in' means such parameters can in theory be optimized if the compiler has the proper sources, so it would seem right to leverage it.
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 11 February 2013 at 10:53:40 UTC, deadalnix wrote:
 On Monday, 11 February 2013 at 10:04:55 UTC, Namespace wrote:
 But what if we want to pass a struct with intent as value?
 With this solution, we don't have much control.
 In general, I like the idea, but we should mark such parameter
 with '&' or whatever, so at least we can still take some 
 influence.

That is the whole point, everything appear as if it is passed by value. struct A { uint member; this(this) { // Very long but pure operation. } } void main() { A a; foo(a); assert(a.member = 0); // Pass. } void foo(A a) { // Compiler can choose to pass by ref here. bar(a); } void bar(A a) { // If compiler choose to pass by ref, then it is bar responsibility to create a copy. A smarter move from the compiler is to mark bar as non electable for such optimization. a.member = 5; } In the example above, the compiler is allowed to pass a by ref to foo. As a consequence, the very long operation within the postblit can only be executed once, instead of 2.

I see. Nice idea. But what is the criterion for the compiler to pass 'a' by ref? I'm still therefor, to mark such paramters with '&' or something but that's maybe my C++ background. I'm curious to see if Walter or Andrei say something to the idea.
Feb 11 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.

 Passing by ref to improve performance is not ideal. First this 
 is quite hard to know when it is actually faster to pass by ref 
 and to pass by value, especially in generic code. Secondly it 
 is easy to forget to use ref at some location, and a lot of 
 small performance improvement are lost in the process. Finally, 
 this may be error prone.

 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let me 
 explain.

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter. Here are some rules the compiler can use to know 
 which one to call from callee side :

 The caller is free to call the ref version of the function 
 unless (rules evaluate in order) :
  - The argument is an rvalue (in such case, no postblit is 
 executed as well).
  - The argument is shared.
  - The argument's postblit in not pure (weakly).

 The callee isn't modified for the vanilla function, but must 
 create a local copy of the argument in the following reasons in 
 the ref version :
  - The argument is binded to a mutable ref.(even as hidden 
 argument as for member method).
  - The argument is actually modified.
  - address of anything coming from the struct is taken.

 The compiler is free to apply such treatment only in a branch 
 of the callee, ie :

 // Compiler choose to create an alternative ref version for 
 performance.
 void foo(MyStruct s) {
     if(condition) {
         // Operation require a copy to not alter what the 
 caller see.
         // A s is copied on stack and postblit is called.
         s.field = 5;
     } else {
         // No operation requiring local copy is performed.
         // No local copy is created.
     }
 }

 The compiler is however disallowed to create multiple copies in 
 the callee. If several branches requires it, then the copy have 
 to be made in a common branch.

 Note that the compiler don't HAVE to do this, but is allowed 
 to. Modifying the spec in such way allow the compiler to avoid 
 many copies of struct let us get rid of most ref parameters, 
 keeping them for what they really are for.

+1 It's really ugly to write "const ref Blah blah" all the time when the compiler could it.
Feb 11 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
+1, I've been thinking about similar concepts as well.

This would be particularly useful for Win64. The Win64 ABI 
requires all structs > 64 bits (or of a size which is not a power 
of 2) to be passed by reference. So if a function foo(BigStruct 
s) is invoked, the caller first allocates a copy of s for the 
callee on its own stack (16-bytes aligned) and then passes the 
callee a pointer to the copy (in a register or on the parameters 
stack), instead of passing a copy of s directly on the parameters 
stack. It seems to me that the whole idea of this is to encourage 
byref passing and copying arguments only if required, otherwise 
it doesn't make much sense performance-wise (higher stack memory 
usage due to the additional pointer and need for dereferencing 
the pointer parameter).

I'd propose a small change so that suited structs are passed 
transparently byref only if the parameter is not mutable, e.g., 
for a function foo(const BigStruct s). The compiler would 
therefore not need to analyze the code flow in the callee to 
determine if the parameter is modified and hence a copy is needed.

The compiler would nevertheless need to be quite smart though:

---
struct MyBigStruct { double a, b, c; }
double foo(const MyBigStruct s, double* x)
{
     *x = s.a;
     return s.b;
}
// naive optimization by byref passing
double foo_ref(const ref MyBigStruct s, double* x)
{
     *x = s.a;
     return s.b;
}

MyBigStruct s = { 1, 2, 3 };
double* x = &s.b;
auto bla = foo(s, x); // returns 2; now s.b = 1
s.b = 2;              // reset s.b to 2
bla = foo_ref(s, x);  // returns 1! (the new s.b = 1)
---

So the compiler would need to prove there is no way the argument 
can be modified and handle tricky aliasing issues accordingly.
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 12:16:14 UTC, Namespace wrote:
 I see. Nice idea. But what is the criterion for the compiler to 
 pass 'a' by ref?
 I'm still therefor, to mark such paramters with '&' or 
 something but that's maybe my C++ background.
 I'm curious to see if Walter or Andrei say something to the 
 idea.

A good rule of thumb to know when to pass by ref for perf is : - The struct is big, or contains mixed entities (floats and ints). 2*size_t seems like a good heuristic from my experience. - The struct have a postblit. The compiler doing it is superior to the user marking everything : - The user may forget, getting slow down for nothing. - The user can get it wrong the other way around (pass by ref when it isn't appropriate). - This is really hard to get right in generic code. - This is relatively easy to automate. The obvious drawback is possible code bloat, but that isn't that bad (and can be used as heuristic by the compiler to decide if it should pass by ref or not).
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 14:54:48 UTC, kinke wrote:
 I'd propose a small change so that suited structs are passed 
 transparently byref only if the parameter is not mutable, e.g., 
 for a function foo(const BigStruct s). The compiler would 
 therefore not need to analyze the code flow in the callee to 
 determine if the parameter is modified and hence a copy is 
 needed.

That is overly restrictive. See sample code given in this thread, foo couldn't get the struct by ref in such a case if A contains any indirection.
Feb 11 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
On Monday, 11 February 2013 at 15:12:07 UTC, deadalnix wrote:
 On Monday, 11 February 2013 at 14:54:48 UTC, kinke wrote:
 I'd propose a small change so that suited structs are passed 
 transparently byref only if the parameter is not mutable, 
 e.g., for a function foo(const BigStruct s). The compiler 
 would therefore not need to analyze the code flow in the 
 callee to determine if the parameter is modified and hence a 
 copy is needed.

That is overly restrictive. See sample code given in this thread, foo couldn't get the struct by ref in such a case if A contains any indirection.

Not sure what you mean by A containing any indirections, but I'd simply rewrite your example as follows: void foo(const A a) { // byref passing desirable bar(a); // bar's parameter is mutable => pass a copy (byval) } void bar(A a) { // byval passing a.member = 5; }
Feb 11 2013
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-11 06:52:28 +0000, "deadalnix" <deadalnix gmail.com> said:

 When a function accept a struct, the compiler is free to use that 
 function, or an altered one taking a reference as parameter.

When designing the ABI, you can either create the copy on the caller's side, or the callee's side. If I'm understanding well, you want to have two versions of each function, one copying on the caller's side, one copying on the callee's side, and the caller's codegen would choose which one to use. Copying on the caller's side is better if you're passing rvalues (because the caller can just always skip the copying), while copying on the callee's side is better when you're passing lvalues, because the caller may decide to skip copying if it doesn't need a copy. I'm not sure creating two versions of each function will fly well with Walter. Actually, you say *two* are needed, but that's for a function with one struct parameter; it's more 2^(number of structs parameters) versions you'd need in the general case. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 A good rule of thumb to know when to pass by ref for perf is :
  - The struct is big, or contains mixed entities (floats and 
 ints). 2*size_t seems like a good heuristic from my experience.
  - The struct have a postblit.

 The compiler doing it is superior to the user marking 
 everything :
  - The user may forget, getting slow down for nothing.
  - The user can get it wrong the other way around (pass by ref 
 when it isn't appropriate).
  - This is really hard to get right in generic code.
  - This is relatively easy to automate.

I thought of something like this: void foo(A& a) { // the compiler choose if A should pass by ref or by value. } void bar(A a) { // normal behaviour. } That is identical with 'inline' in C++. You _can_ declare a function as inline, but finally the compiler choose if he really inline the function or not.
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I'm not sure creating two versions of each function will fly 
 well with Walter. Actually, you say *two* are needed, but 
 that's for a function with one struct parameter; it's more 
 2^(number of structs parameters) versions you'd need in the 
 general case.

That's how 'auto ref' currently works. But I do not think that code bloat was the intention of deadalnix. Quite the contrary.
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 15:48:32 UTC, Michel Fortin wrote:
 On 2013-02-11 06:52:28 +0000, "deadalnix" <deadalnix gmail.com> 
 said:

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter.

When designing the ABI, you can either create the copy on the caller's side, or the callee's side. If I'm understanding well, you want to have two versions of each function, one copying on the caller's side, one copying on the callee's side,

That is blatantly wrong. You don't have, the compiler is allowed to, and the copy on callee side isn't mandatory.
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 16:27:29 UTC, Namespace wrote:
 That is identical with 'inline' in C++. You _can_ declare a 
 function as inline, but finally the compiler choose if he 
 really inline the function or not.

Compiler now inline even when inline isn't present, and don't inline when inline is present but this don't make sense. In other terms, inline is the perfect example of why defining stuff like that explicitly make no sense.
Feb 11 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 Feb 2013 10:08:52 -0500, deadalnix <deadalnix gmail.com> wrote:

 A good rule of thumb to know when to pass by ref for perf is :
   - The struct is big, or contains mixed entities (floats and ints).  
 2*size_t seems like a good heuristic from my experience.

Array slices are 2*sizeof(size_t). I would expect them to be always copied and not ref'd. -Steve
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 16:51:22 UTC, Steven Schveighoffer 
wrote:
 On Mon, 11 Feb 2013 10:08:52 -0500, deadalnix 
 <deadalnix gmail.com> wrote:

 A good rule of thumb to know when to pass by ref for perf is :
  - The struct is big, or contains mixed entities (floats and 
 ints). 2*size_t seems like a good heuristic from my experience.

Array slices are 2*sizeof(size_t). I would expect them to be always copied and not ref'd.

First, they alway appears to be copied from the dev perspective. That why I put bunch of restrictions in the proposal. Second, slice are 2*size_t and are not mixed entities (from CPU perspective, pointer are integers). So I don't have numbers, but I expect slice to be faster when passed by copy than when passed by ref.
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Compiler now inline even when inline isn't present, and don't 
 inline when inline is present [...]

 In other terms, inline is the perfect example of why defining 
 stuff like that explicitly make no sense.

That was no criticism. I like to explicitly mark such things, but whatever, I like the idea anyway. I still hope for a response from Walter or Andrei.
Feb 11 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.

 Passing by ref to improve performance is not ideal. First this 
 is quite hard to know when it is actually faster to pass by ref 
 and to pass by value, especially in generic code. Secondly it 
 is easy to forget to use ref at some location, and a lot of 
 small performance improvement are lost in the process. Finally, 
 this may be error prone.

 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let me 
 explain.

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter. Here are some rules the compiler can use to know 
 which one to call from callee side :

I expect this to be a nightmare for both users, who would experience new pile of struct bugs and for developers. How much code would this proposal break? What do you mean by 'altered'? Are you taking about two function versions or a single one? If first, how does it work with linking, and if second, how does it work for different situations? What happens when you use function pointer or a delegate? How __traits works with respect to function type in case of such optimization? What happens if compiler cannot deduce from context information required to make such decision? How does it play with variardic functions? And how such optimization can be disabled?
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 17:15:40 UTC, Maxim Fomin wrote:
 On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about 
 the second one.

 Passing by ref to improve performance is not ideal. First this 
 is quite hard to know when it is actually faster to pass by 
 ref and to pass by value, especially in generic code. Secondly 
 it is easy to forget to use ref at some location, and a lot of 
 small performance improvement are lost in the process. 
 Finally, this may be error prone.

 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let 
 me explain.

 When a function accept a struct, the compiler is free to use 
 that function, or an altered one taking a reference as 
 parameter. Here are some rules the compiler can use to know 
 which one to call from callee side :

I expect this to be a nightmare for both users, who would experience new pile of struct bugs and for developers. How much code would this proposal break?

None.
 What do you mean by 'altered'? Are you taking about two 
 function versions or a single one? If first, how does it work 
 with linking, and if second, how does it work for different 
 situations? What happens when you use function pointer or a 
 delegate? How __traits works with respect to function type in 
 case of such optimization? What happens if compiler cannot 
 deduce from context information required to make such decision? 
 How does it play with variardic functions? And how such 
 optimization can be disabled?

The optimization cannot be used on opaques calls. This include function pointer and alike. The only function that is guaranteed to exist is the one that take the struct by value. The other one is an option that the compiler is allowed to choose to make things faster. It is applicable for variadic function for non variadic argument, not for variadic arguments. Finally, why would you disable something that make your code faster ?
Feb 11 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 11 February 2013 at 17:51:30 UTC, deadalnix wrote:
 Finally, why would you disable something that make your code 
 faster ?

in order to do easier debugging / to avoid implementation bugs
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I'm a bit confused now. It's your intention to create (worst 
case) 2^n permutations of the same function for each potential 
ref parameter (which would be the same behaviour as 'auto ref') 
or that the compiler could pass big structs by ref without code 
bloat?
Feb 11 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 11 February 2013 at 19:14:15 UTC, Namespace wrote:
 I'm a bit confused now. It's your intention to create (worst 
 case) 2^n permutations of the same function for each potential 
 ref parameter (which would be the same behavior as 'auto ref') 
 or that the compiler could pass big structs by ref without code 
 bloat?

For some reason I doubt that's what he means. Seems more often than not only one or two parameter(s) need to be ref-able, so in most cases with 1 variable two (and only two) functions be made and it choose between the two based on the result. Larger than that and another method would have to be selected.
Feb 11 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 11 Feb 2013 07:52:28 +0100
"deadalnix" <deadalnix gmail.com> wrote:

 Ok, We have 2 usages of ref : when you actually need to modify 
 informations, and for performance reasons. Let's talk about the 
 second one.
 
 Passing by ref to improve performance is not ideal. First this is 
 quite hard to know when it is actually faster to pass by ref and 
 to pass by value, especially in generic code. Secondly it is easy 
 to forget to use ref at some location, and a lot of small 
 performance improvement are lost in the process. Finally, this 
 may be error prone.
 
 I'm thinking about it for a while now and I'm now convinced that 
 we should allow the compiler to do that job for us. Let me 
 explain.
 

To be honest, up until recently, I mistakenly thought the compiler DID do this. (Yea, my mistake.) Is it possible I had confused structs with static arrays? Do static arrays do that?
Feb 11 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 02/11/2013 04:31 PM, jerro wrote:
 To be honest, up until recently, I mistakenly thought the compiler DID
 do this. (Yea, my mistake.)

 Is it possible I had confused structs with static arrays? Do static
 arrays do that?

Maybe you were thinking about named return value optimization (which applies to return values, not parameters)?

There is a corresponding optimization for parameters, which can be applied only in some cases. The related guideline in C++ is this: If you are going to make a copy of the parameter inside the function anyway, take the parameter by-value. Here is a related article: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ Especially this part: "Also, although the compiler is normally required to make a copy when a function parameter is passed by value (so modifications to the parameter inside the function can’t affect the caller), it is allowed to elide the copy, and simply use the source object itself, when the source is an rvalue." Ali
Feb 11 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 11 February 2013 at 21:45:11 UTC, Nick Sabalausky 
wrote:
 On Mon, 11 Feb 2013 07:52:28 +0100 "deadalnix" 
 <deadalnix gmail.com> wrote:
 
 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let 
 me explain.
 

To be honest, up until recently, I mistakenly thought the compiler DID do this. (Yea, my mistake.) Is it possible I had confused structs with static arrays? Do static arrays do that?

I'm pretty sure static/fixed arrays are more like structs, and thereby whole copies are made rather than sending a slice. Let's find out. void main() { char[4] test = "test"; writeln(&test, "- main"); fun(test); if (test == "test") writeln("is passed by value/copy"); else { assert(test == "best", "Something's wrong..."); writeln("is passed by slice/ref"); } } void fun(char[4] test){ assert(test == "test"); writeln(&test, "- fun"); test[0] = 'b'; assert(test == "best"); } Output: 18FDD0- main 18FDAC- fun is passed by value/copy
Feb 11 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 11 February 2013 at 22:03:52 UTC, Era Scarecrow wrote:
 Output:

 18FDD0- main
 18FDAC- fun
 is passed by value/copy

Now had the function been 'void fun(char[] test)', then passing a static/fixed array would have errored and you'd be required to send a slice of it's contents, which then is by ref. Seems using the address doesn't seem to be very helpful, so for slices you'd refer to the ptr of the array. I'm sure there's other tests that can be done... to help with the expected behavior //appended to main fun2(test); if (test == "test") writeln("is passed by value/copy"); else { assert(test == "best", "Something's wrong..."); writeln("is passed by slice/ref"); } } void fun2(char[] test){ assert(test == "test"); //&test points to local test not it's contents writeln(test.ptr, "- fun2"); test[0] = 'b'; assert(test == "best"); } new Output: 18FDD0- main 18FDA4- fun is passed by value/copy 18FDD0- fun2 is passed by slice/ref
Feb 11 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Monday, 11 February 2013 at 16:56:38 UTC, deadalnix wrote:
 On Monday, 11 February 2013 at 16:51:22 UTC, Steven 
 Schveighoffer wrote:
 On Mon, 11 Feb 2013 10:08:52 -0500, deadalnix 
 <deadalnix gmail.com> wrote:

 A good rule of thumb to know when to pass by ref for perf is :
 - The struct is big, or contains mixed entities (floats and 
 ints). 2*size_t seems like a good heuristic from my 
 experience.

Array slices are 2*sizeof(size_t). I would expect them to be always copied and not ref'd.

First, they alway appears to be copied from the dev perspective. That why I put bunch of restrictions in the proposal. Second, slice are 2*size_t and are not mixed entities (from CPU perspective, pointer are integers). So I don't have numbers, but I expect slice to be faster when passed by copy than when passed by ref.

The idea of compiler choosing the optimal between: 'T t' and 'ref const(T) t' has been brought up a few times. Here is one attempt at getting numbers to see where a cutoff might be. http://forum.dlang.org/thread/opufykfxwkkjchqcwgrg forum.dlang.org Based on this, and to avoid the boilerplate of read accessors, I use the following heuristic. If others have more friendly ways I'd be interested. Thanks Dan /** Discriminates a pass type by its size */ template PrefersPassByRef(T) { static if(isAssociativeArray!T || isDynamicArray!T) { enum PrefersPassByRef = false; } else static if(T.sizeof > 16 || hasAliasing!T) { enum PrefersPassByRef = true; } else { enum PrefersPassByRef = false; } } /** Discriminates a pass type by its size */ template PreferredPassType(T) { static if(PrefersPassByRef!T) { enum PreferredPassType = `const ref `~T.stringof; } else { enum PreferredPassType = T.stringof; } } /** Provides mixin for making a field read only. * For example mixin(ReadOnly!_fieldName) provides a getter named fieldName. */ template ReadOnly(alias name) { enum v = name.stringof; enum p = name.stringof[1..$]; enum prefersReference = PrefersPassByRef!(typeof(name)); static if(prefersReference) { mixin(` public property auto ref `~p~`() const { return `~v~`; } `); } else { mixin(` public property auto `~p~`() const { return `~v~`; } `); } }
Feb 11 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let me 
 explain.

struct Foo { int x, y; } class Bar { Foo[] foos = [Foo(1, 2)]; void swap(const(Foo) f) { foos[0].x = f.y; foos[0].y = f.x; } } void quux(Bar bar, const(Foo) foo) { bar.swap(foo); } Are the foo parameters allowed to be passed by ref in both these functions? I see no reason why not from your criteria, but doing so changes the program.
Feb 11 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
How about this approach:
You almost need functions, which takes structs as an rvalue, for 
things like:
----
struct A { }
void foo(A a) { }

foo(A());
----
So what's about something like this (Yes I mark it with '&'):
----
struct A { }
void foo(A& a) { }
----
The compiler decides at compile time whether A should be taken by 
ref or by value.
So for example, if A.sizeof > 16, it changes to:
----
void foo(ref A a) {
----
otherwise:
----
void foo(A a) {
----
In the latter case nothing happens for calls like: foo(A());
But in the former case the call:
foo(A());
is changed to:
auto __temp = A(); foo(__temp);
Feb 11 2013
prev sibling next sibling parent "jerro" <a a.com> writes:
 To be honest, up until recently, I mistakenly thought the 
 compiler DID
 do this. (Yea, my mistake.)

 Is it possible I had confused structs with static arrays? Do 
 static
 arrays do that?

Maybe you were thinking about named return value optimization (which applies to return values, not parameters)?
Feb 11 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
On Monday, 11 February 2013 at 14:54:48 UTC, kinke wrote:
 I'd propose a small change so that suited structs are passed 
 transparently byref only if the parameter is not mutable, e.g., 
 for a function foo(const BigStruct s). The compiler would 
 therefore not need to analyze the code flow in the callee to 
 determine if the parameter is modified and hence a copy is 
 needed.

 The compiler would nevertheless need to be quite smart though:

 ---
 struct MyBigStruct { double a, b, c; }
 double foo(const MyBigStruct s, double* x)
 {
     *x = s.a;
     return s.b;
 }
 // naive optimization by byref passing
 double foo_ref(const ref MyBigStruct s, double* x)
 {
     *x = s.a;
     return s.b;
 }

 MyBigStruct s = { 1, 2, 3 };
 double* x = &s.b;
 auto bla = foo(s, x); // returns 2; now s.b = 1
 s.b = 2;              // reset s.b to 2
 bla = foo_ref(s, x);  // returns 1! (the new s.b = 1)
 ---

 So the compiler would need to prove there is no way the 
 argument can be modified and handle tricky aliasing issues 
 accordingly.

Thinking about it some more, I'm fairly convinced the proposal in this thread is just too dangerous. Proving the argument passed transparently byref cannot be modified is just too complex imo; e.g., it could be modified by the callee via aliasing issues shown in the example above, or it could be modified by another thread while the callee is running, hence modifying the callee's parameter at the same time! I think the intended move semantics (byval passing for small structs w/o postblit constructor/destructor, otherwise byref) are only really safe if the argument is an rvalue - the rvalue is guaranteed not to be used after the call, so potential modifications are not visible for the caller, and the rvalue is guaranteed not to be used simultaneously in another thread. Certain lvalue cases could be optimized as well, e.g., if the lvalue is a private variable of the caller (local variable or parameter) AND is not used after the call. --- struct MyBigStruct { double a, b, c; } double bar(MyBigStruct s) { return s.a; } double foo(MyBigStruct s) // s is an lvalue (parameter) { return bar(s); // s NOT used afterwards => byref passing } void main() { MyBigStruct s; // s is an lvalue (local variable) invoke foo(s) in another thread; // s used afterwards => byval if (...) { foo(s); // s used afterwards (next line) => byval s.a += 1; } else foo(s); // s NOT used afterwards => byref } --- So imo parameters need to be denoted by something special like 'auto ref' if a copy is to be elided for performance reasons - not in its current form though (only for templates and leading to code-bloating); instead, rvalues should simply be transformed to lvalues before the call and then passed byref just like ordinary lvalues. And as I've already pointed out a few times in recent discussions, I'm not a fan of 'const auto ref' for not-mutable parameters, so I'd very much like to see 'const ref' for these (allowing rvalues too, just like C++). The function signature therefore clearly indicates that these params are references to the caller's arguments, with all potentially dangerous implications.
Feb 12 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Read my approach. I suggest something like A& a. It's short and 
known from C++.
Only in my approach, I suggest a link between the proposal of 
deadalnix (compiler optimizations) and generally rvalue 
references.
'const ref' will never work the way as we know it from C++. 
Walter and Andrei and many others are totally against it.
However, 'auto ref' is also not a real solution, because 'auto 
ref' generates 2^(n - 1) permuationen of the same function - code 
bloat.
'auto ref' accept of course lvalues and rvalues but you gain no 
performance.
Feb 12 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
On Tuesday, 12 February 2013 at 13:59:45 UTC, Namespace wrote:
 Read my approach. I suggest something like A& a. It's short and 
 known from C++.

... where A& stands for a reference to an A instance. But in your approach it denotes either a plain A instance OR a reference to it, so I don't like your suggestion at all, I'm afraid. Additionally, afaik D/DMD (?) already implements move semantics for rvalues, so 1) the goal of your approach is already implemented and 2) the existing optimization doesn't require any special parameter denotation (plain A is fine).
 Only in my approach, I suggest a link between the proposal of 
 deadalnix (compiler optimizations) and generally rvalue 
 references.

Yes, and I'd extend it for the illustrated lvalue cases as well.
 'const ref' will never work the way as we know it from C++. 
 Walter and Andrei and many others are totally against it.

And there are many others totally in favour of it. ;) I'm still waiting for a plausible argument as to why the callee needs to know whether a passed const reference actually references an lvalue or an rvalue. I'm tired of this const ref discussion, and probably many others are too.
 However, 'auto ref' is also not a real solution, because 'auto 
 ref' generates 2^(n - 1) permuationen of the same function - 
 code bloat.

That's what I said basically regarding the current 'auto ref' implementation.
 'auto ref' accept of course lvalues and rvalues but you gain no 
 performance.

Of course you'd gain performance because lvalues would not be copied (just like 'ref' only). But in contrast to 'ref', you'd also be able to pass rvalues directly (byref), without having to overload the function or turn the rvalue manually to an lvalue right before the call. The thing is that with 'auto ref', you have to determine if the struct is suited for copy-elision and then decorate the params manually with 'auto ref'/'const auto ref'/'const ref' ;). deadalnix listed some good reasons why the compiler should do that for us. But I think I also mentioned good reasons as to why the compiler most likely can't due to the huge complexity involved to make sure code doesn't break. Although it is unlikely to break in most cases, an optimization feature such as this needs to work for ALL cases. This is why I suggested applying deadalnix' intended implicit move semantics only for rvalues and the mentioned, safe lvalue cases. Afaik D already implements move semantics for rvalues, but I guess it doesn't optimize the lvalue cases. For all other cases, I think we sadly need to resort to a revisited 'auto ref' approach.
Feb 12 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Don't get me wrong, I also hope that this unfortunate and lengthy 
discussion ends. And I also like the idea that const ref works as 
in C++.
But I'm sure you can convince neither Walter nor Andrei still the 
core developer team.

And I don't quite understand what speaks against my suggestion.
If the compiler decides that by value is a better solution, then 
structs are received by value, otherwise by ref. But the user 
don't need to worry about it, because, whatever the compiler may 
decide to do, he adapt calls to these functions automatically. It 
is in principle nothing more than what you want.
Feb 12 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
 For all other cases, I think we sadly need to resort to
 a revisited 'auto ref' approach.

I.e., something like this: https://github.com/D-Programming-Language/dmd/pull/1019
Feb 12 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 12 February 2013 at 15:57:42 UTC, kinke wrote:
 For all other cases, I think we sadly need to resort to
 a revisited 'auto ref' approach.

I.e., something like this: https://github.com/D-Programming-Language/dmd/pull/1019

http://forum.dlang.org/thread/nirfuenixutsbgyrcsla forum.dlang.org ;)
Feb 12 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
On Tuesday, 12 February 2013 at 15:53:57 UTC, Namespace wrote:
 Don't get me wrong, I also hope that this unfortunate and 
 lengthy discussion ends. And I also like the idea that const 
 ref works as in C++.
 But I'm sure you can convince neither Walter nor Andrei still 
 the core developer team.

I tried my best a while back, but they sadly didn't take part in the discussion. Just in case, it's summarized in http://forum.dlang.org/thread/zteryxwxyngvyqvukqkm forum.dlang.org. I could live with 'const auto ref' too, but I'd hate having to type these 5 additional characters every time. ;)
 And I don't quite understand what speaks against my suggestion.
 If the compiler decides that by value is a better solution, 
 then structs are received by value, otherwise by ref. But the 
 user don't need to worry about it, because, whatever the 
 compiler may decide to do, he adapt calls to these functions 
 automatically.

Your proposal, if I understood correctly, restricts deadalnix' approach to rvalues only and additionally requires changing the param from 'A' to 'A&'. But iirc rvalues are already passed directly (moved) in D, i.e., they are not copied - so your approach is 1) simply not needed and 2) would require the A -> 'A&' transform (similar to A -> 'auto ref A').
 It is in principle nothing more than what you want.

No, nothing more, but it's already covered by D, without special syntax. I'd like to see 1) the move optimization applied to safe lvalue cases as well, also without requiring syntactic changes; 2) Kenji's 'auto ref' proposal getting pulled in the near future so that we can manually prevent argument copying for the remaining unsafe lvalue cases.
Feb 12 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 2) Kenji's 'auto ref' proposal getting pulled in the near 
 future so that we can manually prevent argument copying for the 
 remaining unsafe lvalue cases.

Maybe in 2065 - if we're lucky. ;) Read also in my thread that I had posted earlier: auto ref - again. There are also one of the rare responses of Andrei to this topic. This problem isn't solved any time soon.
Feb 12 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Maybe in 2065 - if we're lucky. ;)

I meant of course dmd version 2.065, not the year 2065. ;)
Feb 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 18:38:28 UTC, John Colvin wrote:
 On Monday, 11 February 2013 at 17:51:30 UTC, deadalnix wrote:
 Finally, why would you disable something that make your code 
 faster ?

in order to do easier debugging / to avoid implementation bugs

This is where the difference between allowing and enforcing lies.
Feb 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 22:40:44 UTC, Dan wrote:
 On Monday, 11 February 2013 at 16:56:38 UTC, deadalnix wrote:
 On Monday, 11 February 2013 at 16:51:22 UTC, Steven 
 Schveighoffer wrote:
 On Mon, 11 Feb 2013 10:08:52 -0500, deadalnix 
 <deadalnix gmail.com> wrote:

 A good rule of thumb to know when to pass by ref for perf is 
 :
 - The struct is big, or contains mixed entities (floats and 
 ints). 2*size_t seems like a good heuristic from my 
 experience.

Array slices are 2*sizeof(size_t). I would expect them to be always copied and not ref'd.

First, they alway appears to be copied from the dev perspective. That why I put bunch of restrictions in the proposal. Second, slice are 2*size_t and are not mixed entities (from CPU perspective, pointer are integers). So I don't have numbers, but I expect slice to be faster when passed by copy than when passed by ref.

The idea of compiler choosing the optimal between: 'T t' and 'ref const(T) t' has been brought up a few times. Here is one attempt at getting numbers to see where a cutoff might be. http://forum.dlang.org/thread/opufykfxwkkjchqcwgrg forum.dlang.org Based on this, and to avoid the boilerplate of read accessors, I use the following heuristic. If others have more friendly ways I'd be interested. Thanks Dan /** Discriminates a pass type by its size */ template PrefersPassByRef(T) { static if(isAssociativeArray!T || isDynamicArray!T) { enum PrefersPassByRef = false; } else static if(T.sizeof > 16 || hasAliasing!T) { enum PrefersPassByRef = true; } else { enum PrefersPassByRef = false; } } /** Discriminates a pass type by its size */ template PreferredPassType(T) { static if(PrefersPassByRef!T) { enum PreferredPassType = `const ref `~T.stringof; } else { enum PreferredPassType = T.stringof; } } /** Provides mixin for making a field read only. * For example mixin(ReadOnly!_fieldName) provides a getter named fieldName. */ template ReadOnly(alias name) { enum v = name.stringof; enum p = name.stringof[1..$]; enum prefersReference = PrefersPassByRef!(typeof(name)); static if(prefersReference) { mixin(` public property auto ref `~p~`() const { return `~v~`; } `); } else { mixin(` public property auto `~p~`() const { return `~v~`; } `); } }

This is a lot o code and don't handle some cases. For instance struct A { long a; double b; } is generally better passed by ref, where struct A { long a; long b; } is better passed by value.
Feb 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 11 February 2013 at 23:16:55 UTC, Peter Alexander 
wrote:
 On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
 I'm thinking about it for a while now and I'm now convinced 
 that we should allow the compiler to do that job for us. Let 
 me explain.

struct Foo { int x, y; } class Bar { Foo[] foos = [Foo(1, 2)]; void swap(const(Foo) f) { foos[0].x = f.y; foos[0].y = f.x; } } void quux(Bar bar, const(Foo) foo) { bar.swap(foo); } Are the foo parameters allowed to be passed by ref in both these functions? I see no reason why not from your criteria, but doing so changes the program.

I guess the constraint are too lax. Is it possible to get around that without creating a cascade of special cases ? I frankly don't know, I have to dig more into this.
Feb 12 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Tuesday, 12 February 2013 at 17:33:08 UTC, deadalnix wrote:
 This is a lot o code

Fortunately, like a lot of code you don't need to look at it to use it. That is the purpose of it. struct ReductionMap(K, V, alias reduction_op = "+", alias init = 0) { mixin ReadOnly!_dataMap; mixin ReadOnly!_reduction; alias V[K] DataMap; ... private { DataMap _dataMap; V _reduction = init; } }
 and don't handle some cases. For instance

I did not say it handled everything and if you have strategies that will allow me to simply, declaratively get a better selection between the two pass types I'd incorporate it. If and until the language changes, what other choices are there? I just used the numbers to come up with a heuristic, which I imagine, given the state of things is how any one makes the choice. The only difference is the choice is somewhat formalized.
 struct A {
     long a;
     double b;
 }

 is generally better passed by ref, where

 struct A {
     long a;
     long b;
 }

 is better passed by value.

Any performance numbers? Even if that were true, is it realistic to expect a compiler to get it right each time? Thanks Dan
Feb 12 2013
prev sibling next sibling parent "kinke" <noone hotmail.com> writes:
On Tuesday, 12 February 2013 at 13:34:10 UTC, kinke wrote:
 I think the intended move semantics (byval passing for small 
 structs w/o postblit constructor/destructor, otherwise byref) 
 are only really safe if the argument is an rvalue - the rvalue 
 is guaranteed not to be used after the call, so potential 
 modifications are not visible for the caller, and the rvalue is 
 guaranteed not to be used simultaneously in another thread. 
 Certain lvalue cases could be optimized as well, e.g., if the 
 lvalue is a private variable of the caller (local variable or 
 parameter) AND is not used after the call.

Sorry, please discard these lvalue cases, they aren't safe, i.e., analog to my earlier example: --- struct BigStruct { long a, b, c; } long foo(const BigStruct s, ref long c) { // s is the callee's copy of the argument c = s.a + s.b + s.c; return s.c; } long foo_ref(const ref BigStruct s, ref long c) { // s is a reference to the caller's argument c = s.a + s.b + s.c; return s.c; } BigStruct s = { 1, 2, 3 }; long r1 = foo(s, s.c); assert(s.c == 6 && r1 == 3); // returns callee's s.c s.c = 3; // reset long r2 == foo_ref(s, s.c); // returns caller's s.c assert(s.c == 6 && r2 == 6); --- So aliasing issues (the caller's argument is modified indirectly via another parameter/global variable) are able to break code when passing _any_ lvalue transparently byref, even if it's not used afterwards. So only rvalues are really safe for move semantics, i.e., they can't be modified by another thread or indirectly by the callee via aliasing AND modifications are not visible to the caller after the call.
Feb 12 2013
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 02/11/2013 07:52 AM, deadalnix wrote:
 Ok, We have 2 usages of ref : when you actually need to modify
 informations, and for performance reasons. Let's talk about the second one.

 Passing by ref to improve performance is not ideal. First this is quite
 hard to know when it is actually faster to pass by ref and to pass by
 value, especially in generic code. Secondly it is easy to forget to use
 ref at some location, and a lot of small performance improvement are
 lost in the process. Finally, this may be error prone.

 I'm thinking about it for a while now and I'm now convinced that we
 should allow the compiler to do that job for us. Let me explain.

 When a function accept a struct, the compiler is free to use that
 function, or an altered one taking a reference as parameter. Here are
 some rules the compiler can use to know which one to call from callee
 side :

 The caller is free to call the ref version of the function unless (rules
 evaluate in order) :
   - The argument is an rvalue (in such case, no postblit is executed as
 well).
   - The argument is shared.
   - The argument's postblit in not pure (weakly).

 The callee isn't modified for the vanilla function, but must create a
 local copy of the argument in the following reasons in the ref version :
   - The argument is binded to a mutable ref.(even as hidden argument as
 for member method).
   - The argument is actually modified.
   - address of anything coming from the struct is taken.

 The compiler is free to apply such treatment only in a branch of the
 callee, ie :

 // Compiler choose to create an alternative ref version for performance.
 void foo(MyStruct s) {
      if(condition) {
          // Operation require a copy to not alter what the caller see.
          // A s is copied on stack and postblit is called.
          s.field = 5;
      } else {
          // No operation requiring local copy is performed.
          // No local copy is created.
      }
 }

 The compiler is however disallowed to create multiple copies in the
 callee. If several branches requires it, then the copy have to be made
 in a common branch.

 Note that the compiler don't HAVE to do this, but is allowed to.
 Modifying the spec in such way allow the compiler to avoid many copies
 of struct let us get rid of most ref parameters, keeping them for what
 they really are for.

You can easily create a function that turns values into rvalues if it's opportune. template isBetterToPassAsValue(T) { enum isBetterToPassAsValue = ...; } T cheapPass(T)(ref T t) if (isBetterToPassAsValue!T) { return t; } ref T cheapPass(T)(ref T t) if (!isBetterToPassAsValue!T) { return t; } T cheapPass(T)(T t) if (isBetterToPassAsValue!T) { return move(t); } void foo(T)(auto ref T t) { // ... } void bar() { S1 s1; foo(cheapPass(s1)); // passed by ref S2 s2; foo(cheapPass(s2)); // passed by value }
Feb 12 2013
next sibling parent Martin Nowak <code dawg.eu> writes:
On 02/13/2013 12:34 AM, Martin Nowak wrote:
 You can easily create a function that turns values into rvalues if it's
 opportune.

Actually there is also a nice template based implementation of this in phobos (std.algorithm.forward). https://github.com/D-Programming-Language/phobos/blob/8bf6997acfdbe81442e4c3e4c3500b9197ffaaca/std/algorithm.d#L2002
Feb 12 2013
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 12 February 2013 at 23:49:04 UTC, Martin Nowak wrote:
 On 02/13/2013 12:34 AM, Martin Nowak wrote:
 You can easily create a function that turns values into 
 rvalues if it's
 opportune.

Actually there is also a nice template based implementation of this in phobos (std.algorithm.forward). https://github.com/D-Programming-Language/phobos/blob/8bf6997acfdbe81442e4c3e4c3500b9197ffaaca/std/algorithm.d#L2002

But that does not solve the problem. And it's not pleasant to use.
Feb 13 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 12 February 2013 at 17:29:07 UTC, deadalnix wrote:
 On Monday, 11 February 2013 at 18:38:28 UTC, John Colvin wrote:
 On Monday, 11 February 2013 at 17:51:30 UTC, deadalnix wrote:
 Finally, why would you disable something that make your code 
 faster ?

in order to do easier debugging / to avoid implementation bugs

This is where the difference between allowing and enforcing lies.

Of course, but it's always nice to be able to disable any optimization globally for any given compilation. I personally like gcc's approach where you have very fine grained control over all optimisations. Something like this should have a compiler switch to enable/disable.
Feb 12 2013