Would the following code:
for (int i = 1; i < di.count; i++)
{  assert (node.di.entry[i - 1].key < node.di.entry[i].key);  }

be optimized away if compiled under -release?

On Wednesday, January 09, 2013 16:14:47 Charles Hixson wrote:
> Would the following code:
> for (int i = 1; i < di.count; i++)
> { assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
> 
> be optimized away if compiled under -release?

If you compile with -release, assertions will be compiled out, so you'd get

for(int i = 1; i < d.count; i++)
{}

However, I don't believe that -release enables any optimizations - that's what -O is for - so the loop would likely be left in with -release. If you compile with -O, it _might_ be optimized out. I don't know. It would be great if it did, but you'd have to test it to know for sure. But that's not hard to do at all (in fact, it wouldn't have taken much longer to test it then to post your question). In fact, if I test it now...

This code

import std.conv;
import std.datetime;
import std.stdio;

void main()
{
 auto sw = StopWatch(AutoStart.yes);

 foreach(i; 0 .. 50_000_000)
 {}

 writeln(to!Duration(sw.peek));
}

takes just over 37ms on my machine. If I remove the foreach, it takes about 3 hnsecs. So clearly, dmd does _not_ optimize out the loop. I have no idea what gdc and ldc do though.

- Jonathan M Davis

On Thursday, 10 January 2013 at 00:40:21 UTC, Jonathan M Davis wrote:
> So clearly, dmd does _not_ optimize out the loop. I have no idea what
> gdc and ldc do though.

Wow, DMD doesn't optimize it away indeed, just confirmed that by a look at the assembly.

LDC does delete the loop though, starting at -O1, and I can't imagine that GDC wouldn't as well.

David

On Thu, Jan 10, 2013 at 02:03:47AM +0100, David Nadlinger wrote:
> On Thursday, 10 January 2013 at 00:40:21 UTC, Jonathan M Davis wrote:
> >So clearly, dmd does _not_ optimize out the loop. I have no idea what gdc and ldc do though.
> 
> Wow, DMD doesn't optimize it away indeed, just confirmed that by a look at the assembly.

I tested DMD on a loop containing assert(true);, and apparently that *is* optimized out with -O. So DMD does catch simpler cases of no-op loops. Probably the OP's code is a bit beyond DMD's optimizer to recognize as a no-op loop.


> LDC does delete the loop though, starting at -O1, and I can't imagine that GDC wouldn't as well.
[...]

Yeah, something like that would be a sitting duck for GCC's optimizer.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Thursday, 10 January 2013 at 01:14:42 UTC, H. S. Teoh wrote:
> I tested DMD on a loop containing assert(true);, and apparently that
> *is* optimized out with -O.

I tested it with the program from Jonathan's post – still has an empty inc/cmp/jl loop in there with -O -release (x86_64).

David

On 01/09/2013 04:40 PM, Jonathan M Davis wrote:
> On Wednesday, January 09, 2013 16:14:47 Charles Hixson wrote:
>> Would the following code:
>> for (int i = 1; i<  di.count; i++)
>> { assert (node.di.entry[i - 1].key<  node.di.entry[i].key); }
>>
>> be optimized away if compiled under -release?
>
> If you compile with -release, assertions will be compiled out, so you'd get
>
> for(int i = 1; i<  d.count; i++)
> {}
>
> However, I don't believe that -release enables any optimizations - that's what
> -O is for - so the loop would likely be left in with -release. If you compile
> with -O, it _might_ be optimized out. I don't know. It would be great if it
> did, but you'd have to test it to know for sure. But that's not hard to do at
> all (in fact, it wouldn't have taken much longer to test it then to post your
> question). In fact, if I test it now...
>
> This code
>
> import std.conv;
> import std.datetime;
> import std.stdio;
>
> void main()
> {
>   auto sw = StopWatch(AutoStart.yes);
>
>   foreach(i; 0 .. 50_000_000)
>   {}
>
>   writeln(to!Duration(sw.peek));
> }
>
> takes just over 37ms on my machine. If I remove the foreach, it takes about 3
> hnsecs. So clearly, dmd does _not_ optimize out the loop. I have no idea what
> gdc and ldc do though.
>
> - Jonathan M Davis
Thank you for a reply that was both useful and informative.

P.S.:  Not knowing where to look, it would have taken me a lot more time that your estimate.  I'm not sure that a few hours would have sufficed, as I seem to be running into various compiler problems that I don't understand well enough to characterize.

On Thursday, 10 January 2013 at 00:21:48 UTC, Charles Hixson wrote:
> Would the following code:
> for (int i = 1; i < di.count; i++)
> {  assert (node.di.entry[i - 1].key < node.di.entry[i].key);  }
>
> be optimized away if compiled under -release?

If you write it as:
//----
version(assert)
{
    for (int i = 1; i < di.count; i++)
        assert (node.di.entry[i - 1].key < node.di.entry[i].key);
}
//----

Then I 100% guarantee that it will not appear in release mode ;)

I know it's *kind of* off topic in regards to the original question, but if you have a chunk of code that is destined only for assertive validation, you might as well put it in an assert block:
Not only is it guaranteed behavior (as opposed to relying on the compiler). It also makes reviewing simpler, as it is self documenting. Without it, a reviewer might waste effort thinking about the loop conditions*

*Also: What is "di"? If it is a user defined type, and if "count" is not declared as const, then the compiler may not optimize away the loop itself, because it is worried about any side effect from calling di.count.

di is a struct containing *NO* functions.  count, however, is a @property, it just returns a counter variable, but that's not a local property.

I *LIKE* the
version(assert)
{
...
}
choice.  I'd been thinking about debug.  I didn't know that version (or possibly assert) could be used that way.
On 01/10/2013 01:13 AM, monarch_dodra wrote:
> On Thursday, 10 January 2013 at 00:21:48 UTC, Charles Hixson wrote:
>> Would the following code:
>> for (int i = 1; i < di.count; i++)
>> { assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
>>
>> be optimized away if compiled under -release?
>
> If you write it as:
> //----
> version(assert)
> {
> for (int i = 1; i < di.count; i++)
> assert (node.di.entry[i - 1].key < node.di.entry[i].key);
> }
> //----
>
> Then I 100% guarantee that it will not appear in release mode ;)
>
> I know it's *kind of* off topic in regards to the original question, but
> if you have a chunk of code that is destined only for assertive
> validation, you might as well put it in an assert block:
> Not only is it guaranteed behavior (as opposed to relying on the
> compiler). It also makes reviewing simpler, as it is self documenting.
> Without it, a reviewer might waste effort thinking about the loop
> conditions*
>
> *Also: What is "di"? If it is a user defined type, and if "count" is not
> declared as const, then the compiler may not optimize away the loop
> itself, because it is worried about any side effect from calling di.count.

On 01/09/2013 04:14 PM, Charles Hixson wrote:
> Would the following code:
> for (int i = 1; i < di.count; i++)
> { assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
>
> be optimized away if compiled under -release?

It looks like you can use std.algorithm.isSorted instead:

  http://dlang.org/phobos/std_algorithm.html#isSorted

    assert(isSorted(di));

Or perhaps:

    assert(isSorted(node.di.entry[0 .. di.count]));

That code will disappear in release mode.

Additionally, if the O(N) complexity of that check is not acceptable even in non-release mode there is std.range.assumeSorted:

  http://dlang.org/phobos/std_range.html#.assumeSorted

assumeSorted makes very few comparisons so it may miss occasional sort issues. Also, it is not really for checking but more for range algorithms that require or work better with a sorted range.

Ali

On 01/10/2013 08:41 AM, Ali Çehreli wrote:
> On 01/09/2013 04:14 PM, Charles Hixson wrote:
>> Would the following code:
>> for (int i = 1; i < di.count; i++)
>> { assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
>>
>> be optimized away if compiled under -release?
>
> It looks like you can use std.algorithm.isSorted instead:
>
> http://dlang.org/phobos/std_algorithm.html#isSorted
>
> assert(isSorted(di));
>
> Or perhaps:
>
> assert(isSorted(node.di.entry[0 .. di.count]));
>
> That code will disappear in release mode.
>
> Additionally, if the O(N) complexity of that check is not acceptable
> even in non-release mode there is std.range.assumeSorted:
>
> http://dlang.org/phobos/std_range.html#.assumeSorted
>
> assumeSorted makes very few comparisons so it may miss occasional sort
> issues. Also, it is not really for checking but more for range
> algorithms that require or work better with a sorted range.
>
> Ali
Unfortunately, entry is also a struct.  key isn't its only member.  If there's some other reason to define a opCmp on entry, that would be a good approach.

OTOH, if :
version(assert)
{...}
works as suggested by monarch_dodra above, that will allow me to avoid the problem.