On Sun, 15 Mar 2015 19:34:11 +0000, Kagamin wrote:

> Optimizer optimizes any code, it doesn't matter, what the code does.

wow! i wrote an excellect optimizer yesterday. it optimizes any code to `nop`...

On Sunday, 15 March 2015 at 19:39:06 UTC, ketmar wrote:
> wow! i wrote an excellect optimizer yesterday. it optimizes any code to
> `nop`...

Why, rm didn't work for you?

On Sunday, 15 March 2015 at 08:45:55 UTC, Jonathan M Davis wrote:
> On Saturday, March 14, 2015 15:35:24 Ali Çehreli via Digitalmars-d wrote:
>> On 03/14/2015 03:23 PM, deadalnix wrote:
>>
>>  > But, for some reason, the topic come up again and again from C++ devs
>>  > that have no idea the optimization guys solved the issues for years now.
>>
>> If we are talking about C++, it is not possible to not take that copy
>> for user-defined types. Due to separate compilation, the compiler does
>> not even see the definition of operator++(int).
>>
>> And the compiler cannot replace calls to operator++(int) with calls to
>> operator++() (when the return value is not used) because the programmer
>> may have done different things than the canonical implmentation of
>> post-increment.
>
> Exactly. In C++, there isn't even a guarantee than an overloaded
> postincrement operator is even related to an overloaded preincrement
> operator. One could do addition while the other does subtraction - or
> nothing at all. Sure, bad code won't do that, but the compiler doesn't know
> whether you're being an idiot or not. So, it can't assume that overloaded
> preincrement and postincrement are at all related and therefore can't
> optimize a postincrement to a preincrement for overloaded operators.
>
> The result is that simply always using preincrement when you need to
> increment but don't specifically need to postincrement is a good habit to
> get into. Its impact is likely to be minimal in most cases, but it doesn't
> cost you anything, and you can't rely on the compiler's ability to optimize,
> because the C++ standards committee didn't restrict the overloaded increment
> (or decrement) operators enough to enable the compiler to optimize them
> properly.
>
>> C++ needs a rule like D's, which will never be there.
>
> Yep. By making it so that you only overload a single operator for both
> versions of increment, we avoid the whole problem in D, similar to how
> having opCmp avoids bugs related to having to define each comparison
> operator individually as is the case in C++.
>
> It'll likely always bug me though when I see i++ when ++i would work, even
> if it doesn't matter in D. It's just too ingrained in me, I guess. :)
>
> - Jonathan M Davis

Yeah, one can rationalize all he/she wants. Thing is:
 - Either the operator implementation is simple and the optimizer will see through it.
 - Or it is quite complex and the extra copy will barely show up in benchmark anyway.

The only case where it makes sense is with separate compilation, as Ali mentioned. But in which case, same as above, either the thing is simple, and you loose way more in calling convention than you could save by optimizing a copy away, or the implementation is complex so that the calling convention or the extra copy do not matter.

On Sun, 15 Mar 2015 19:46:39 +0000, Kagamin wrote:

> On Sunday, 15 March 2015 at 19:39:06 UTC, ketmar wrote:
>> wow! i wrote an excellect optimizer yesterday. it optimizes any code to `nop`...
> 
> Why, rm didn't work for you?

no. it removes code, and i want to optimize code.

Here is some data.

vibe.d

foreach:
505 matches across 74 files
++var:
15 matches across 8 files
var++:
168 matches across 37 files
20 would brake if changed meaning to ++var

deadcode (IDE)

foreach:
366 matches across 68 files
++var:
62 matches across 10 files
var++:
111 matches across 30 files
17 would brake if changed meaning to ++var

phobos

foreach:
2007 matches across 77 files
++var:
508 matches across 59 files
var++;
1579 matches across 90 files
N/A would brake if changed meaning to ++var

DMD

foreach:
1338 matches across 219 files
++var:
564 matches across 139 files
var++;
3285 matches across 292 files
N/A would brake if changed meaning to ++var

foreach number was obtained by using find string algorithm
var++ number was obtained by using regex ([^\;\s\+\(\)\]\,\"]+)\+\+
++var number was obtained by using regex \+\+([^\;\s\+\(\)\]\,\"]+)

On Friday, 20 March 2015 at 21:56:44 UTC, welkam wrote:
> Here is some data.
>
> vibe.d
>
> foreach:
> 505 matches across 74 files
> ++var:
> 15 matches across 8 files
> var++:
> 168 matches across 37 files
> 20 would brake if changed meaning to ++var
>
> deadcode (IDE)
>
> foreach:
> 366 matches across 68 files
> ++var:
> 62 matches across 10 files
> var++:
> 111 matches across 30 files
> 17 would brake if changed meaning to ++var
>
> phobos
>
> foreach:
> 2007 matches across 77 files
> ++var:
> 508 matches across 59 files
> var++;
> 1579 matches across 90 files
> N/A would brake if changed meaning to ++var
>
> DMD
>
> foreach:
> 1338 matches across 219 files
> ++var:
> 564 matches across 139 files
> var++;
> 3285 matches across 292 files
> N/A would brake if changed meaning to ++var
>
> foreach number was obtained by using find string algorithm
> var++ number was obtained by using regex ([^\;\s\+\(\)\]\,\"]+)\+\+
> ++var number was obtained by using regex \+\+([^\;\s\+\(\)\]\,\"]+)

Now end up you data gathering :

Turn them around (sed can do that for you), recompile, benchmark, and see that it does not change anything at the end.

On Friday, 20 March 2015 at 22:01:35 UTC, deadalnix wrote:
>
> Now end up you data gathering :
>
> Turn them around (sed can do that for you), recompile, benchmark, and see that it does not change anything at the end.

I do not know exact implementation of D compiler but I guess it generates code and then optimises it away. If thats the case then you slow down your compilation unnecessarily. Also having language construct that is being used only 15% of the time correctly is not great. And D has foreach. In C++ world this is even worse.

Is this a big problem? Not really, but its still a problem.

On Friday, 20 March 2015 at 22:52:54 UTC, welkam wrote:
> On Friday, 20 March 2015 at 22:01:35 UTC, deadalnix wrote:
>>
>> Now end up you data gathering :
>>
>> Turn them around (sed can do that for you), recompile, benchmark, and see that it does not change anything at the end.
>
> I do not know exact implementation of D compiler but I guess it generates code and then optimises it away. If thats the case then you slow down your compilation unnecessarily.

You can include measurement of compile time in your benchmark.

> Also having language construct that is being used only 15% of the time correctly is not great. And D has foreach. In C++ world this is even worse.
>
> Is this a big problem? Not really, but its still a problem.

I'm waiting the numbers that support this assertion with great impatience.

On 3/20/15 2:56 PM, welkam wrote:
> Here is some data.
[snip]

Actually var++ is more efficient than ++var for integrals. I cover that in one of my optimization talks available publicly. -- Andrei

On 3/20/15 3:52 PM, welkam wrote:
> On Friday, 20 March 2015 at 22:01:35 UTC, deadalnix wrote:
>>
>> Now end up you data gathering :
>>
>> Turn them around (sed can do that for you), recompile, benchmark, and
>> see that it does not change anything at the end.
>
> I do not know exact implementation of D compiler but I guess it
> generates code and then optimises it away. If thats the case then you
> slow down your compilation unnecessarily. Also having language construct
> that is being used only 15% of the time correctly is not great. And D
> has foreach. In C++ world this is even worse.
>
> Is this a big problem? Not really, but its still a problem.

Are you sure you're not missing the part where D's ++var and var++ generate identical code if the result isn't taken? -- Andrei