www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - release mode optimization

reply Charles Hixson <charleshixsn earthlink.net> writes:
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?
Jan 09 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 09 2013
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Jan 09 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 09 2013
parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 09 2013
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
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.
Jan 09 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Jan 10 2013
parent Charles Hixson <charleshixsn earthlink.net> writes:
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.
Jan 10 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jan 10 2013
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Jan 10 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 10 January 2013 at 20:24:02 UTC, Charles Hixson 
wrote:
 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
OTOH, if : version(assert) {...} works as suggested by monarch_dodra above, that will allow me to avoid the problem.
Well, you check if something is sorted by hand, if the code to check it already exists?
 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.
I'm not entirely sure what you mean by that. The fact that it is a struct should pose no problem. As for whether or you need to define opCmp, keep in mind that "isSorted" (and *anything else* related to sorted in general) take a "less" paramter http://dlang.org/phobos/std_algorithm.html#isSorted So you can write an external "foo" function, that takes 2 entries, and returns the "lowest" one (by any custom ordering), and then call: isSorted!foo(myStuff)
Jan 10 2013