<div class="gmail_quote">On 16 March 2012 18:37, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Actually, as has been mentioned, swizzling can be done very nicely inside the language.<br></blockquote><div><br></div><div>How? The only example I saw in this thread was your from()/to() approach, which Timon said didn't actually work...?</div>
<div><br></div><div><br></div></div><div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 3/16/12 6:29 AM, Manu wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Requiring inlining to make it efficient is not enough. The proposed MRV</blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">ABI would solve this not only for inlines, but for all multi-assignment<br>type constructs, including distant function calls.<br></div></blockquote><br>If changing the ABI is on the table, I wonder whether we can improve it for all structures, not only for multiple return types. Overall I agree that defining a specialized ABI for leaving multiple values on the stack would be marginally more efficient, but (a) I don't know by how much, and (b) I don't know whether it's worth changing the language.</blockquote>
<div><br></div><div>It might be that this technology is simpler to implement as applied to all structs (which would include tuples). That way it may additionally address the current problem with slices and delegates. If it applies too all structs, there probably needs to be a cut-off heuristic though, since explicit structs would tend to be a lot bigger than a few MRV values, and named return values is probably better in that context. Implementation details would reveal themselves when trying to write the code I think, ie, where to draw the line (structure size/recursion, etc).</div>
<div><br></div><div>(a) 'Marginally' spread across the entire program eventually adds up to a lot, especially if it finds its self in hot loops. C/C++ compilers have extremely aggressive low level optimisers. There is obviously someone who agrees that that effort and reduction in compiler performance is worthwhile, or they wouldn't do it...</div>
<div>In terms of benchmarks (the quantity of value you are looking for), it probably won't make so much difference to existing code, because people avoid returning structs by value like the plague It's just something you simply don't do. But if it were a real feature that were reliable, I can see it quickly replace returning through references passed in the parameter list (a horrible concept conceptually, effectively a hack), and it would start to show its value as more and more code were written that way. We free up an argument register in the call where we would have previously passed the ref/pointer, and the return doesn't produce a memory write+read (an LHS hazard). This is a good few opcodes, memory access, and elimination of a major architectural hazard. Repeat this throughout your code base... the only reason it's not in C, is because the ABI far too engraved and can never be changed.</div>
<div><br></div><div>(b) Is it a change to the language? Just a change to the ABI with respect to returning a tuple.</div></div><div>The change to the language is the unpack syntax, which should be argued on a completely separate basis.</div>