Re: status of D optimizers benefiting from contracts ?
On Monday, 10 November 2014 at 10:27:19 UTC, bearophile wrote: In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better. In my experience asserts don't show such distinction, and it's impractical to decide such things in advance. So I think, a compiler switch makes more sense.
Re: status of D optimizers benefiting from contracts ?
On 11/09/2014 05:24 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Sun, Nov 09, 2014 at 04:12:06PM +, bearophile via Digitalmars-d-learn wrote: H. S. Teoh: Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point. And it caused a storm, because it's an awfully bad idea. [...] It's only a bad idea because people abuse assert() where it's not appropriate. T Some do, but that's basically orthogonal to why this is a bad idea.
Re: status of D optimizers benefiting from contracts ?
On 11/09/2014 11:39 PM, H. S. Teoh via Digitalmars-d-learn wrote: The original meaning of assert() is what assume() means nowadays, whereas nowadays what people think of as assert() is actually what enforce() does in Phobos. T No.
Re: status of D optimizers benefiting from contracts ?
On Sunday, 9 November 2014 at 22:41:29 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Sun, Nov 09, 2014 at 09:57:21PM +, eles via Digitalmars-d-learn wrote: On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: >H. S. Teoh: > >>It's only a bad idea because people abuse assert() where >>it's not >>appropriate. > >It's a bad idea because Walter seems unable to understand the >difference between verifying and proving. I fail to see the difference between assert() and a hypothetical assume(). The original meaning of assert() is what assume() means nowadays, whereas nowadays what people think of as assert() is actually what enforce() does in Phobos. No, enforce() is obviously intended for verifying user input, not for checking program logic, that's why it throws an Exception, not an Error. The documentation even says so explicitly: http://dlang.org/phobos/std_exception.html#.enforce
Re: status of D optimizers benefiting from contracts ?
Meta: On the other hand, making assert a built-in that provides optimization hints has been proposed for C++17: Thank you for the link. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4154.pdf But that behavour is on request (using NDEBUG = strong), it's not suddenly becoming the default for D as Walter suggested: << To satisfy as many users as possible, four levels of assertion are provided: • Default: assert evaluates its condition and generates a diagnostic upon failure. • NDEBUG = strong: assert has no side effects, but the implementation may use the condition, and if it would fail, the behavior is undefined. This provides optimal hints. • NDEBUG = strict: The assert expression is fully parsed and semantically checked, but no evaluation occurs. The behavior is still defined even if it would evaluate as false, but this may be considered unlikely. • NDEBUG defined as empty or an integer literal: The assert operands are syntactically a balanced-token-seq. Otherwise this is the same as strict mode. • Other identifiers in the expansion of NDEBUG are reserved to the standard for future expansion, except for identifiers usually reserved to the library. If you write a program from the start using NDEBUG=strong you are relying on a different semantics for assert. It's essentially a different kind of assert. You can't take D programs and silently change the basic semantics of all asserts under them. And still, in many cases you don't want to use NDEBUG=strong, that's why there are also other available behaviours like NDEBUG=strict that is an intermediate point. I think this proposal n4154 is a bit over-engineered (as it often happens to C++), but it avoids most of the faults in Walter ideas: it avoids breaking existing code (because the default behavour doesn't change), allows optimizations on request, etc. In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better. Walter is right in his very strong engineer desire to keep designs as simple as possible; but often giving the same name to things with different semantics doesn't reduce the complexity, it just increases the confusion. I greatly prefer when things with different semantics have cleanly distinct names. Bye, bearophile
Re: status of D optimizers benefiting from contracts ?
On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: H. S. Teoh: It's only a bad idea because people abuse assert() where it's not appropriate. It's a bad idea because Walter seems unable to understand the difference between verifying and proving. Bye, bearophile On the other hand, making assert a built-in that provides optimization hints has been proposed for C++17: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4154.pdf
Re: status of D optimizers benefiting from contracts ?
On Sun, Nov 09, 2014 at 09:57:21PM +, eles via Digitalmars-d-learn wrote: > On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: > >H. S. Teoh: > > > >>It's only a bad idea because people abuse assert() where it's not > >>appropriate. > > > >It's a bad idea because Walter seems unable to understand the > >difference between verifying and proving. > > I fail to see the difference between assert() and a hypothetical > assume(). The original meaning of assert() is what assume() means nowadays, whereas nowadays what people think of as assert() is actually what enforce() does in Phobos. T -- In order to understand recursion you must first understand recursion.
Re: status of D optimizers benefiting from contracts ?
On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: H. S. Teoh: It's only a bad idea because people abuse assert() where it's not appropriate. It's a bad idea because Walter seems unable to understand the difference between verifying and proving. I fail to see the difference between assert() and a hypothetical assume().
Re: status of D optimizers benefiting from contracts ?
Thanks. Laeeth.
Re: status of D optimizers benefiting from contracts ?
H. S. Teoh: It's only a bad idea because people abuse assert() where it's not appropriate. It's a bad idea because Walter seems unable to understand the difference between verifying and proving. Bye, bearophile
Re: status of D optimizers benefiting from contracts ?
On Sun, Nov 09, 2014 at 04:12:06PM +, bearophile via Digitalmars-d-learn wrote: > H. S. Teoh: > > >Walter *did* mention recently that he was planning to eventually take > >advantage of information in assert()'s as optimizer hints. Not sure > >when this will happen, though, but it seems inevitable at some point. > > And it caused a storm, because it's an awfully bad idea. [...] It's only a bad idea because people abuse assert() where it's not appropriate. T -- I'm still trying to find a pun for "punishment"...
Re: status of D optimizers benefiting from contracts ?
H. S. Teoh: Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point. And it caused a storm, because it's an awfully bad idea. Bye, bearophile
Re: status of D optimizers benefiting from contracts ?
On Sun, Nov 09, 2014 at 02:45:29PM +, bearophile via Digitalmars-d-learn wrote: > Laeeth Isharc: > > >Walter Bright suggests that a supplementary benefit of using contrats > >is helping the compiler make optimisations. > > I think no D compilers do this, currently. And no one knows when such > things will be added, if ever. [...] Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point. T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
Re: status of D optimizers benefiting from contracts ?
Laeeth Isharc: Walter Bright suggests that a supplementary benefit of using contrats is helping the compiler make optimisations. I think no D compilers do this, currently. And no one knows when such things will be added, if ever. Bye, bearophile
status of D optimizers benefiting from contracts ?
https://www.youtube.com/watch?v=e2F2pqeMLuw&list=PL4EvMyUrlAJmEfs8l6oW2BlnALiDu7kGy 31 minutes in, Walter Bright suggests that a supplementary benefit of using contrats is helping the compiler make optimisations. He uses the example of being able to do faster 32 bit arithmetic when the variables are longs but per contract within the bounds for 32 bits. I wondered to what extent D compilers are doing this already (peeking at the contract), and what plans if any there are to incorporate these in generating fast code. Thanks. Laeeth
