www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - status of D optimizers benefiting from contracts ?

reply "Laeeth Isharc" <laeethnospam spammenot-laeeth.com> writes:
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
Nov 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 09 2014
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Sun, Nov 09, 2014 at 02:45:29PM +0000, 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
Nov 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 09 2014
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Sun, Nov 09, 2014 at 04:12:06PM +0000, 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"...
Nov 09 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 09 2014
next sibling parent "Laeeth Isharc" <laeethnospam spammenot-laeeth.com> writes:
Thanks.  Laeeth.
Nov 09 2014
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
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().
Nov 09 2014
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Sun, Nov 09, 2014 at 09:57:21PM +0000, 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.
Nov 09 2014
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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 +0000, 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
Nov 10 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Nov 10 2014
prev sibling parent reply "Meta" <jared771 gmail.com> writes:
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
Nov 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 10 2014
parent "Kagamin" <spam here.lot> writes:
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.
Nov 11 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/09/2014 05:24 PM, H. S. Teoh via Digitalmars-d-learn wrote:
 On Sun, Nov 09, 2014 at 04:12:06PM +0000, 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.
Nov 10 2014