On Thu, Jul 31, 2014 at 06:12:11PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/31/2014 3:21 PM, Daniel Gibson wrote:
> >And I agree with your stance on those fine-grained optimization switches from your other post. GCC currently has 191 flags the influence optimization[1]
> 
> Just consider this from a testing standpoint. As I mentioned previously, optimizations interact with each other to produce emergent behavior. GCC has 191 factorial different optimizers. Google's calculator puts 191! at infinity, which it might as well be.
[...]

It's actually a number with "only" 360+ digits. :-) There are far larger numbers between it and infinity, but I get the point, it's impractically huge, and certainly poorly covered by tests.


T

-- 
"Uhh, I'm still not here." -- KD, while "away" on ICQ.

On Thu, Jul 31, 2014 at 06:19:59PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/31/2014 3:07 PM, David Bregman wrote:
[...]
> >I would think the easiest way is to just not inject the assumption when inside @safe code, but I don't know anything about the compiler internals.
> >
> >Even for @system code, I'm on the fence about whether asserts should affect codegen in release, it doesn't seem like a clear tradeoff to make: safety vs some dubious optimization gains.
> 
> So why do you want assume() with no checking whatsoever? Does anybody want that? Why are we even discussing such a misfeature?
[...]

Yikes. That sounds *really* scary. If assume() doesn't insert any checks, and yet the compiler's optimizer takes it as truth, it leads to horrible consequences like:

	int add(int x, int y) {
		assume(x + y == x - y);
		return x + y;  // what does this do?!
	}

At least, if assume() inserts checks, blatantly ridiculous things like the above will quickly and frequently cause runtime aborts, instead of directing the optimizer to do obviously wrong things that are untraceable from the actual code. But if we do that, then assume() starts to sound more and more like assert()...


T

-- 
Bomb technician: If I'm running, try to keep up.

Am 01.08.2014 03:12, schrieb Walter Bright:
> On 7/31/2014 3:21 PM, Daniel Gibson wrote:
>> And I agree with your stance on those fine-grained optimization
>> switches from
>> your other post. GCC currently has 191 flags the influence
>> optimization[1]
>
> Just consider this from a testing standpoint. As I mentioned previously,
> optimizations interact with each other to produce emergent behavior. GCC
> has 191 factorial different optimizers. Google's calculator puts 191! at
> infinity, which it might as well be.

Yep, also a good point.
(Actually it's 187 -f* options, the rest is -O* which can't be combined of course and some of them most probably imply many of the -f* switches, but it'll still be an unmanageable/untestable amount of possible configurations)

>
>
>> However, what about an extra flag for "unsafe" optimizations?
>
> There's been quite a creep of adding more and more flags. Each one of
> them is, in a way, a failure of design, and we are all too quick to
> reach for that.

Well, it would be one additional flag that would also imply -O ...
but this should probably be reevaluated when problems with overaggressive optimization actually occur.

>
>
>> I *don't*
>> want it to e.g. remove writes to memory that isn't read afterwards
>
> That's what volatileStore() is for.
>

Ah, sounds nice, having a standard way to do that is certainly a good thing! :-)
I looked at the pull request ( https://github.com/D-Programming-Language/druntime/pull/892 ) and I wonder if maybe an additional function that's equivalent to memset() and overwrites a whole range of memory could be added.
As memset() in C is usually much faster than iterating over the data and setting it to $value one by one, I guess this kind of function could provide a speedup here as well.

>
>> or make assumptions based on assertions (that are disabled in the
>> current compile mode).
>
> This is inexorably coming. If you cannot live with it, I suggest writing
> your own version of assert, using the Phobos 'enforce' implementation as
> a model. It'll do what you want.

Yeah. But please update the assert() documentation so people can know about this.
I also wonder if this might be commonly needed and could be a good addition to enforce() in phobos

>
>
>> And maybe a warning mode that tells me about "dead"/"superfluous" code
>> that
>> would be eliminated in an optimized build so I can check if that would
>> break
>> anything for me in that respect without trying to understand the asm
>> output
>> would be helpful.
>
> If you compile DMD with -D, and then run it with -O --c, it will present
> you with a list of all the data flow optimizations performed on the
> code. It's very useful for debugging the optimizer. Although I think
> you'll find it illuminating, you won't find it very useful - for one
> thing, a blizzard of info is generated.
>

Sounds interesting, thanks for the hint :-)
This would probably be useful information that an IDE could (optionally) display alongside the actual code - I guess that could make debugging issues that only happen in optimized code/release mode much easier (if you can narrow your problem down to a few functions).

Cheers,
Daniel

"Artur Skawina via Digitalmars-d"  wrote in message news:mailman.324.1406835164.16021.digitalmars-d@puremagic.com...

> > The corner case is "assert(0)".  It means "if the program got to here, the impossible
> has happened."
>
> It's vaguely defined, overloaded, and not currently treated that way.
> Arguably it could mean 'this path won't ever be reached, trust me', but
> redefining it now is obviously not possible. (doing this would of course
> make assert(0) extremely dangerous)

You should probably read the spec on assert.  The assert(0) case is already defined that way. 

On 08/01/14 04:33, Daniel Murphy via Digitalmars-d wrote:
> "Artur Skawina via Digitalmars-d"  wrote in message news:mailman.324.1406835164.16021.digitalmars-d@puremagic.com...
> 
>> > The corner case is "assert(0)".  It means "if the program got to here, > the impossible
>> has happened."
>>
>> It's vaguely defined, overloaded, and not currently treated that way. Arguably it could mean 'this path won't ever be reached, trust me', but redefining it now is obviously not possible. (doing this would of course make assert(0) extremely dangerous)
> 
> You should probably read the spec on assert.  The assert(0) case is already defined that way.

No, that definition is contradictory ("vaguely defined" was an euphemism).
Requiring either AssertError or halting execution precludes treating assert(0)
as "unreachable code". Removing that requirement would change the meaning of
every existing (reachable) assert(0); all of them would then trigger undefined
behavior...

artur

On Friday, 1 August 2014 at 01:20:04 UTC, Walter Bright wrote:
> I'm rather astonished you'd take that position. It opens a huge door wide for undefined behavior, and no obvious way of verifying that the assume() is correct.
>
> I'm confident that if D introduced such behavior, the very first comment would be "I need it to insert a runtime check on demand."

If no one else has said it, I'll be the first one to say it now:

If `assume` is implemented, the only sensible thing is to have it verify the assumption under most circumstances and remove the check (but keep the assumption for the optimizer to use) under release code.

Boom, done. Sorry guys, but it's the truth, the idea of `assume` is worthless and dangerous if there doesn't exist any way for it to actually check the assumption when you're trying to debug your code. Walter is absolutely right on that.

Though, I'm gonna say that `assert` doing all the things you're suggesting it should do is a bit iffy in `@safe` code. That much has also been shown pretty strongly as well. `assert` is essentially an `@trusted` concept that can cause bad things to happen in `@safe` code, but there's no real way to show the user that. Updating the documentation on it probably won't cut it alone. Maybe assert should be made illegal in `@safe` code or there should be some way to mark it that it's basically trusted to be correct (`trusted_assert`? .. or enable `@trusted` blocks of code and make `assert` effectively `@system`? The second would be a better feature, IMO ... more widely useful, like Rust's `unsafe` blocks).

I think this conversation has shown a bit of a weakness in using `assert` as currently spec'd in `@safe` code, so we probably should come up with some proposals on how to effectively fix that (make it obvious that bad `assert`s will break your `@safe` code).

On 7/31/2014 2:21 PM, Sean Kelly wrote:
> Thoughts?

If a process detects a logic error, then that process is in an invalid state that is unanticipated and unknown to the developer. The only correct solution is to halt that process, and all processes that share memory with it.

Anything less is based on faith and hope. If it is medical, flight control, or banking software, I submit that operating on faith and hope is not acceptable.

If it's a dvr or game, who cares :-) My dvr crashes regularly needing a power off reboot.

On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
> But if we do that, then assume() starts to sound more and more like assert()...

I see that my posts are starting to work :-)

On Friday, 1 August 2014 at 03:45:55 UTC, Chris Cain wrote:
> If `assume` is implemented, the only sensible thing is to have it verify the assumption under most circumstances and remove the check (but keep the assumption for the optimizer to use) under release code.
>
> Boom, done. Sorry guys, but it's the truth, the idea of `assume` is worthless and dangerous if there doesn't exist any way for it to actually check the assumption when you're trying to debug your code. Walter is absolutely right on that.

I think you might actually be arguing for our side of the
argument but don't realize it.

Assume is an inherently unsafe and dangerous idea. Some have
pointed out that assume has potential usefulness in a VERY
limited set of cases, but I don't think anyone is arguing that is
not a dangerous thing.

Personally I think any form of assume sounds like a bad idea and
a very dangerous thing, that is why I (and others) are against
the idea of making assert act like assume in -release. It's not
that we are arguing for the addition of assume, it's that we
don't want assert to act like assume in -release. Our reaction to
the idea of making assert act like assume in -release is because
of the fact that assume IS so dangerous.

I don't think anyone is actually arguing for the addition of
assume.

On Friday, 1 August 2014 at 04:36:13 UTC, Walter Bright wrote:
> On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
>> But if we do that, then assume() starts to sound more and more like assert()...
>
> I see that my posts are starting to work :-)

I don't think we are arguing for the addition of assume, we are
arguing about the redefinition of assert to act like assume in
-release.