digitalmars.D.learn - status of D optimizers benefiting from contracts ?
- Laeeth Isharc (11/11) Nov 09 2014 https://www.youtube.com/watch?v=e2F2pqeMLuw&list=PL4EvMyUrlAJmEfs8l6oW2B...
- bearophile (5/7) Nov 09 2014 I think no D compilers do this, currently. And no one knows when
- H. S. Teoh via Digitalmars-d-learn (8/15) Nov 09 2014 [...]
- bearophile (4/9) Nov 09 2014 And it caused a storm, because it's an awfully bad idea.
- H. S. Teoh via Digitalmars-d-learn (7/14) Nov 09 2014 [...]
- bearophile (5/7) Nov 09 2014 It's a bad idea because Walter seems unable to understand the
- Laeeth Isharc (1/1) Nov 09 2014 Thanks. Laeeth.
- eles (3/8) Nov 09 2014 I fail to see the difference between assert() and a hypothetical
- H. S. Teoh via Digitalmars-d-learn (7/18) Nov 09 2014 The original meaning of assert() is what assume() means nowadays,
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (6/26) Nov 10 2014 No, enforce() is obviously intended for verifying user input, not
- Timon Gehr (2/6) Nov 10 2014 No.
- Meta (4/11) Nov 09 2014 On the other hand, making assert a built-in that provides
- bearophile (52/56) Nov 10 2014 But that behavour is on request (using NDEBUG = strong), it's not
- Kagamin (4/15) Nov 11 2014 In my experience asserts don't show such distinction, and it's
- Timon Gehr (2/14) Nov 10 2014 Some do, but that's basically orthogonal to why this is a bad idea.
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
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
On Sun, Nov 09, 2014 at 02:45:29PM +0000, bearophile via Digitalmars-d-learn wrote:Laeeth Isharc:[...] 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 HesseWalter 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.
Nov 09 2014
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
On Sun, Nov 09, 2014 at 04:12:06PM +0000, bearophile via Digitalmars-d-learn wrote:H. S. Teoh:[...] 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"...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.
Nov 09 2014
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
"Laeeth Isharc" <laeethnospam spammenot-laeeth.com> 
On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:H. S. Teoh:I fail to see the difference between assert() and a hypothetical assume().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.
Nov 09 2014
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: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.H. S. Teoh:I fail to see the difference between assert() and a hypothetical assume().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.
Nov 09 2014
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: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:On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile 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.H. S. Teoh:I fail to see the difference between assert() and a hypothetical assume().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.
Nov 10 2014
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. TNo.
Nov 10 2014
On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote:H. S. Teoh: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.pdfIt'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
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.pdfBut 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
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
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:Some do, but that's basically orthogonal to why this is a bad idea.H. S. Teoh:[...] It's only a bad idea because people abuse assert() where it's not appropriate. TWalter *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.
Nov 10 2014