Re: Do a class invariants affect -release builds?
On 12/6/15 6:01 PM, Andrew LaChance wrote: On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote: On 12/5/15 6:06 PM, Andrew LaChance wrote: I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks! I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers. So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked. Rather than completely ripping out the invariant system. I don't think that's true. The invariant is called as part of function execution. Using obj2asm, the code emitted for an empty class function is vastly larger without -release. -Steve
Re: Do a class invariants affect -release builds?
On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote: On 12/5/15 6:06 PM, Andrew LaChance wrote: I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks! I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. -Steve I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers. So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked. Rather than completely ripping out the invariant system.
Do a class invariants affect -release builds?
I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!
Re: Do a class invariants affect -release builds?
On 12/5/15 6:06 PM, Andrew LaChance wrote: I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks! I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. -Steve
Re: Do a class invariants affect -release builds?
On 12/5/15 6:54 PM, Chris Wright wrote:
I've never used a release build of anything. Bounds checking isn't that
expensive.
void main()
{
int[] arr = new int[10];
assert(arr.capacity == 1000); // obviously wrong
arr[10] = 5;
}
dmd -release -boundscheck=on testboundscheck.d
./testboundscheck
core.exception.RangeError@testboundscheck.d(5): Range violation
4 testboundscheck 0x00010df8454d
_d_arraybounds + 97
5 testboundscheck 0x00010df77da6
testboundscheck.__array + 38
6 testboundscheck 0x00010df77d71 _Dmain + 49
7 testboundscheck 0x00010df94e83
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
8 testboundscheck 0x00010df94dbb void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 55
9 testboundscheck 0x00010df94e28 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() + 44
10 testboundscheck 0x00010df94dbb void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 55
11 testboundscheck 0x00010df94d0d _d_run_main + 497
12 testboundscheck 0x00010df77e0f main + 15
13 libdyld.dylib 0x7fff928d15c8 start + 0
14 ??? 0x 0x0 + 0
-Steve
Re: Do a class invariants affect -release builds?
On Sat, 05 Dec 2015 23:06:22 +, Andrew LaChance wrote:
> I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which
> mentions:
>
> "Calls to the druntime invariant handler are emitted in release build
> also and there is no way to turn them off. Even if the class does not
> have any invariants the invariant handler will always be called, walk
> the class hirarchy and generate multiple cache misses without actually
> doing anything."
>
> I was curious if this was still true today (the post was written 3 years
> ago in Sept 2012).
>
> Thanks!
It's not true today, as you can test yourself:
class Foo {
invariant {
assert(false);
}
string str() {
return this.toString;
}
}
void main() {
import std.stdio;
writeln(new Foo().str);
}
$ rdmd invar.d
core.exception.AssertError@invar.d(3): Assertion failure
$ rdmd -release invar.d
invar.Foo
I've never used a release build of anything. Bounds checking isn't that
expensive.
