www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - We should deprecate -release

reply Steven Schveighoffer <schveiguy gmail.com> writes:
The `-release` flag is equivalent to `-O -boundscheck=safeonly 
-inline`.

I think we should remove it. If you want no bounds checks, you 
should have to really want it enough to type that whole 
monstrosity in. It's trivial to avoid bounds checks by using 
`.ptr[index]` in ` system` code. In my dub projects, I rewrite 
the release mode to keep bounds checks for all code, it's that 
important.

What do you think? Deprecate for 3 versions, then remove.

-Steve
Jul 12
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sat, Jul 13, 2024 at 01:55:16AM +0000, Steven Schveighoffer via
Digitalmars-d wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly -inline`.
 
 I think we should remove it. If you want no bounds checks, you should
 have to really want it enough to type that whole monstrosity in. It's
 trivial to avoid bounds checks by using `.ptr[index]` in ` system`
 code. In my dub projects, I rewrite the release mode to keep bounds
 checks for all code, it's that important.
 
 What do you think? Deprecate for 3 versions, then remove.


[...]

+1.


T

-- 
Fact is stranger than fiction.
Jul 12
prev sibling next sibling parent Mike Shah <mshah.475 gmail.com> writes:
On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.

 I think we should remove it. If you want no bounds checks, you 
 should have to really want it enough to type that whole 
 monstrosity in. It's trivial to avoid bounds checks by using 
 `.ptr[index]` in ` system` code. In my dub projects, I rewrite 
 the release mode to keep bounds checks for all code, it's that 
 important.

 What do you think? Deprecate for 3 versions, then remove.

 -Steve


+1 on less flags if the equivalent exist already.

I think it's better(principle of least surprise) if developers 
explicitly turn on/off or what level (i.e. safe only) for 
boundschecking as well.
Jul 12
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.


_Almost_: 
https://github.com/dlang/dmd/blob/82eee6f4e0291e58803dc4e86a6ea236094e91ea/compiler/src/dmd/link.d#L272

That particular... quirk, has been there since at least the C++ 
transition. Is it still needed?
I don't use windows so I have no way of checking, I suspect not 
though.


 I think we should remove it...
 What do you think? Deprecate for 3 versions, then remove.


Sounds good to me.

Nic
Jul 12
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 13 July 2024 at 04:43:07 UTC, Nicholas Wilson wrote:

 On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
 wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.


 _Almost_:


Actually I got that wrong. There is:
* that that small Windows linker thing
* it does not imply `-O` nor does it imply `-inline`
* it does imply `-boundscheck=safeonly`
* it _also_ implies everything in `-check=off` (except for 
boundscheck, which is set to `safeonly`), that is to say it 
additionally disables: invariants, (`in` and `out`) contracts, 
asserts, and switch errors.
Jul 12
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Saturday, 13 July 2024 at 05:06:02 UTC, Nicholas Wilson wrote:

 * it does not imply `-O` nor does it imply `-inline`


This was a surprise for me! For a long time I thought -release 
implied these...

So -release is even more useless than I remembered. We definitely 
should get rid of it.

-Steve
Jul 12
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 I think we should remove it. What do you think? Deprecate for 3 
 versions, then remove.


First thing we need to do is go through [the test 
suite](https://github.com/search?q=repo%3Adlang%2Fdmd+%22-release%22+lan
uage%3AD&type=code) and determine why (i.e. what bits of its implications)
`-release` is required in those tests, and replace it with the switches that
need to be tested.

Any help with the archeology much appriciated.
Jul 12
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Why -release is the way it is:

I got sick of journalists running benchmarks using compilers they weren't 
familiar with. They never spent any effort learning what the switches were.

The big vendors would wine and dine them and show them exactly how to run their 
compilers. With mine, they never talked to me. I wouldn't even know they did a 
review until it hit the news stand.

They'd use the wrong switches, the code would run slow, and I'd get a bad
review.

The -release switch means "make the fastest code". Make it easy for the 
journalists to do the right thing.

Nobody new to D will know to use -O -boundscheck-safeonly -inline. They'll just 
get a "D is slow" result and move on.
Jul 12
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Saturday, 13 July 2024 at 05:35:53 UTC, Walter Bright wrote:

 Why -release is the way it is:

 I got sick of journalists running benchmarks using compilers 
 they weren't familiar with. They never spent any effort 
 learning what the switches were.

 The big vendors would wine and dine them and show them exactly 
 how to run their compilers. With mine, they never talked to me. 
 I wouldn't even know they did a review until it hit the news 
 stand.

 They'd use the wrong switches, the code would run slow, and I'd 
 get a bad review.

 The -release switch means "make the fastest code". Make it easy 
 for the journalists to do the right thing.

 Nobody new to D will know to use -O -boundscheck-safeonly 
 -inline. They'll just get a "D is slow" result and move on.


I think it's fair to say no "journalists" are reviewing D in 
print. For sure, people who try to run benchmarks will at least 
look for the proper optimization flags, and I bet nobody is 
looking to remove bounds checks.

Let's just remove it. What it does now is fool people into 
thinking this is for when you want to release your 
library/application. If nothing else, it should be renamed to 
-removesafetychecks or something.

Note, I was wrong about the -O and -inline being implied -- you 
still have to put those in. -release just gets rid of all the 
safety checks.

-Steve
Jul 12
next sibling parent claptrap <clap trap.com> writes:
On Saturday, 13 July 2024 at 05:55:13 UTC, Steven Schveighoffer 
wrote:


 I think it's fair to say no "journalists" are reviewing D in 
 print. For sure, people who try to run benchmarks will at least 
 look for the proper optimization flags, and I bet nobody is 
 looking to remove bounds checks.

 Let's just remove it. What it does now is fool people into 
 thinking this is for when you want to release your 
 library/application. If nothing else, it should be renamed to 
 -removesafetychecks or something.

 Note, I was wrong about the -O and -inline being implied -- you 
 still have to put those in. -release just gets rid of all the 
 safety checks.


Leave the flag in place but have the compiler print the following 
message...

"DMD optimized code is sloooowww, try using LDC instead"



 Jul 13



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/12/2024 10:55 PM, Steven Schveighoffer wrote:

 I think it's fair to say no "journalists" are reviewing D in print. For sure, 


In print, no, online certainly, and when they're evaluating whether to use D or 
not, absolutely.



 people who try to run benchmarks will at least look for the proper
optimization 
 flags, and I bet nobody is looking to remove bounds checks.


What they'll do is compare it to C and C++, neither of which does bounds
checks, 
and on the same code C and C++ will be faster, and D will be slow, and that
will 
be the result of the benchmark. They will not look deeper.

First impressions are very very hard to dislodge. I have a lot of experience 
with this.



 Let's just remove it. What it does now is fool people into thinking this is
for 
 when you want to release your library/application. If nothing else, it should
be 
 renamed to -removesafetychecks or something.


It's simply not apparent from the documentation the path to the fastest code. 
Nobody doing a quick benchmark is going to try -removesafetychecks.



 Note, I was wrong about the -O and -inline being implied -- you still have to 
 put those in. -release just gets rid of all the safety checks.


Are you sure? It says in the documentation they are.



 Jul 13



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 14/07/2024 4:44 AM, Walter Bright wrote:

 Note, I was wrong about the -O and -inline being implied -- you still 
 have to put those in. -release just gets rid of all the safety checks.


 
 Are you sure? It says in the documentation they are.


Nothing is screaming that it does turn on optimizations.

https://github.com/search?q=repo%3Adlang%2Fdmd%20params.release&type=code

https://github.com/dlang/dmd/blob/9a5ce0e1efe4d395a436e2c6c1cdf7039320e0e0/compiler/src/dmd/main.d#L995



 Jul 13



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


See my reply to Vladimir.



 Jul 13



prev sibling next sibling parent reply Dukc <ajieskola gmail.com>  writes:


Walter Bright kirjoitti 13.7.2024 klo 8.35:

 The -release switch means "make the fastest code". Make it easy for the 
 journalists to do the right thing.
 
 Nobody new to D will know to use -O -boundscheck-safeonly -inline. 
 They'll just get a "D is slow" result and move on.


Maybe we should have two release switches then. `-release-safe` and 
`-release-nochecks`, listed side-by-side in the docs. Then a reviewer 
(or an ordinary user) can hardly notice there is one without noticing 
the other.



 Jul 14



  parent  ryuukk_ <ryuukk.dev gmail.com>  writes:


On Sunday, 14 July 2024 at 19:29:09 UTC, Dukc wrote:

 Walter Bright kirjoitti 13.7.2024 klo 8.35:

 The -release switch means "make the fastest code". Make it 
 easy for the journalists to do the right thing.
 
 Nobody new to D will know to use -O -boundscheck-safeonly 
 -inline. They'll just get a "D is slow" result and move on.


 Maybe we should have two release switches then. `-release-safe` 
 and `-release-nochecks`, listed side-by-side in the docs. Then 
 a reviewer (or an ordinary user) can hardly notice there is one 
 without noticing the other.


`-release-safe` `-release-fast`



 Jul 14



prev sibling  parent reply Sergey <kornburn yandex.ru>  writes:


On Saturday, 13 July 2024 at 05:35:53 UTC, Walter Bright wrote:

 Why -release is the way it is:

 I got sick of journalists running benchmarks using compilers 
 they weren't familiar with. They never spent any effort 
 learning what the switches were.

 The big vendors would wine and dine them and show them exactly 
 how to run their compilers. With mine, they never talked to me. 
 I wouldn't even know they did a review until it hit the news 
 stand.

 They'd use the wrong switches, the code would run slow, and I'd 
 get a bad review.

 The -release switch means "make the fastest code". Make it easy 
 for the journalists to do the right thing.

 Nobody new to D will know to use -O -boundscheck-safeonly 
 -inline. They'll just get a "D is slow" result and move on.


I'm not sure what are you talking about honestly.
First of all 'D benchmarker' here. So which 
impressions/observations I have based on my experience:
1) No journalists are interested in D... at all.
And 'D is slow' usually not because of the compiler or flags, but 
because Phobos/runtime/library implementation.
2) People sometimes adding D to their benchmarks, but most 
usually it is somebody from the community.
3) Community pretty aware of 'not using dmd in any benchmarks', 
but the problem not in this.
4) As many people already said the problem is in 'misleading' 
name. Because benchmarkers also sometime want to use 'the flags 
that will be used in production'. And many other languages have 
'release' flags exactly for these purposes:

Zig: "Standard optimization options allow the person running zig 
build to select between Debug, ReleaseSafe, ReleaseFast, and 
ReleaseSmall. By default none of the release options are 
considered the preferable choice by the build script, and the 
user must make a decision in order to create a release build."

Rust: "
$ cargo build
     Finished dev [unoptimized + debuginfo] target(s) in 0.0s
$ cargo build --release
     Finished release [optimized] target(s) in 0.0s
The dev and release are these different profiles used by the 
compiler."

So Dub is doing fine with 'release' build option (having 
'release-nobounds' in case it is what developer wants) and also 
it is possible to configure the release build flags.



 Jul 17



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On Thursday, 18 July 2024 at 06:32:20 UTC, Sergey wrote:

 So Dub is doing fine with 'release' build option (having 
 'release-nobounds' in case it is what developer wants) and also 
 it is possible to configure the release build flags.


No, dub uses -release. You have to override the release options 
to keep assert/bounds checks. As we did in the related posts 
benchmark: 
https://github.com/jinyus/related_post_gen/blob/7e189c8892e26e3b78e83112ef8910655e87b193/d_v2/dub.json#L11

To reiterate, `-release` disables bounds checks in everything 
*but* ` safe` code. The 'release-nobounds' build type also 
disables bounds checks in ` safe` code.

-Steve



 Jul 18



prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.


What? No it's not.

It's equivalent to `-check=invariant=off -check=in=off 
-check=out=off -check=bounds=safeonly -check=assert=off 
-check=switch=off` (and what Nicholas pointed out).

`-O` and `-inline` are orthogonal to `-release` (and to each 
other).

(But the rest of your post makes sense with that in mind so I 
think that may have been what you meant?)



 Jul 13



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:

 It's equivalent to `-check=invariant=off -check=in=off -check=out=off 
 -check=bounds=safeonly -check=assert=off -check=switch=off` (and what Nicholas 
 pointed out).
 
 `-O` and `-inline` are orthogonal to `-release` (and to each other).



Hmm, checking the actual implementation, you're right. Someone must have
changed 
it at some point. -release is supposed to be "fastest code". Need to fix that!



 Jul 13



 next sibling parent reply Zoadian <no no.no>  writes:


On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:

 On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:

 It's equivalent to `-check=invariant=off -check=in=off 
 -check=out=off -check=bounds=safeonly -check=assert=off 
 -check=switch=off` (and what Nicholas pointed out).
 
 `-O` and `-inline` are orthogonal to `-release` (and to each 
 other).



 Hmm, checking the actual implementation, you're right. Someone 
 must have changed it at some point. -release is supposed to be 
 "fastest code". Need to fix that!


then rename it to -benchmark.



 Jul 14



  parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Sun, Jul 14, 2024 at 12:52:36PM +0000, Zoadian via Digitalmars-d wrote:

 On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:

 On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:

 It's equivalent to `-check=invariant=off -check=in=off
 -check=out=off -check=bounds=safeonly -check=assert=off
 -check=switch=off` (and what Nicholas pointed out).
 
 `-O` and `-inline` are orthogonal to `-release` (and to each
 other).


 
 
 Hmm, checking the actual implementation, you're right. Someone must
 have changed it at some point. -release is supposed to be "fastest
 code".  Need to fix that!


 
 then rename it to -benchmark.


+1.  Calling it -release is misleading and breaks safety guarantees.
That's very bad.

Alternatively, just redirect -release to running ldc2 instead. In almost
every D program I've written, ldc2 produces an executable that runs
30-40% faster than the same program compiled by dmd (sometimes even
50%).  No amount of suppressing bounds checks is going to give you that
kind of performance boost, so why break safety over marginal gains that
isn't winning you any benchmarks anyway?  Just admit it and have
-release run ldc2. Even with bounds checks still enabled, you get an
instant 30% performance boost.  *That's* what's gonna catch attention,
not some half-baked safety-breaking switch in a suboptimal optimizer
that's going to lose out to C benchmarks anyway.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long



 Jul 14



prev sibling  parent reply Guillaume Piolat <first.name gmail.com>  writes:


On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:

 On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:

 It's equivalent to `-check=invariant=off -check=in=off 
 -check=out=off -check=bounds=safeonly -check=assert=off 
 -check=switch=off` (and what Nicholas pointed out).
 
 `-O` and `-inline` are orthogonal to `-release` (and to each 
 other).



 Hmm, checking the actual implementation, you're right. Someone 
 must have changed it at some point. -release is supposed to be 
 "fastest code". Need to fix that!


I honestly don't really care if -release exists or does the right 
thing, as long as

dub -b release-nobounds gives me the (reasonably) fastest 
possible thing



 Jul 14



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 15/07/2024 3:36 AM, Guillaume Piolat wrote:

 On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:

 On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:

 It's equivalent to `-check=invariant=off -check=in=off -check=out=off 
 -check=bounds=safeonly -check=assert=off -check=switch=off` (and what 
 Nicholas pointed out).

 `-O` and `-inline` are orthogonal to `-release` (and to each other).



 Hmm, checking the actual implementation, you're right. Someone must 
 have changed it at some point. -release is supposed to be "fastest 
 code". Need to fix that!


 
 I honestly don't really care if -release exists or does the right thing, 
 as long as
 
 dub -b release-nobounds gives me the (reasonably) fastest possible thing


For reference:

https://dub.pm/dub-reference/buildtypes/

```js
         "release": {
             "buildOptions": ["releaseMode", "optimize", "inline"]
         },
         "release-debug": {
             "buildOptions": ["releaseMode", "optimize", "inline", 
"debugInfo"]
         },
         "release-nobounds": {
             "buildOptions": ["releaseMode", "optimize", "inline", 
"noBoundsCheck"]
         }
```

And:

```
It's recommended to avoid this build type and instead change the 
algorithms that are affected by this the most to do a single bounds 
check before many array accesses and operate on the ptr field following 
that. This results in the same performance improvements while not 
harming safety.
```



 Jul 14



prev sibling  parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On Saturday, 13 July 2024 at 15:28:36 UTC, Vladimir Panteleev 
wrote:

 On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
 wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.


 What? No it's not.


I was wrong. I was used to dub release mode (which does include 
those switches), so I forgot what the compiler -release switch 
actually does.


 It's equivalent to `-check=invariant=off -check=in=off 
 -check=out=off -check=bounds=safeonly -check=assert=off 
 -check=switch=off` (and what Nicholas pointed out).


Thanks, it is good to have this written down. Perhaps this 
actually should be in the docs at least.


 (But the rest of your post makes sense with that in mind so I 
 think that may have been what you meant?)


The biggest problem I have, I guess, is that it's called 
"release". It fools people into thinking you should use it for 
released code.

-Steve



 Jul 14



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/14/2024 1:44 PM, Steven Schveighoffer wrote:

 The biggest problem I have, I guess, is that it's called "release". It fools 
 people into thinking you should use it for released code.


It's an issue I've run into repeatedly. Reviewers not familiar with a compiler 
look for a "release" switch for benchmarking.



 Jul 15



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 16/07/2024 6:14 AM, Walter Bright wrote:

 On 7/14/2024 1:44 PM, Steven Schveighoffer wrote:

 The biggest problem I have, I guess, is that it's called "release". It 
 fools people into thinking you should use it for released code.


 
 It's an issue I've run into repeatedly. Reviewers not familiar with a 
 compiler look for a "release" switch for benchmarking.


Right, but it's dmd we are talking about.

A compiler that no matter what switches are set internally or externally 
cannot compete with ldc or gdc.

It is better to slap a message both in the version/help message of the 
compiler and on the site that says "don't use dmd for reviewing of 
performance of D use ldc/gdc instead".

Given this, it is better to simply remove the switch as it fools people 
into doing unsafe things that give them a very bad day.



 Jul 15



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/15/2024 11:20 AM, Richard (Rikki) Andrew Cattermole wrote:

 Right, but it's dmd we are talking about.
 
 A compiler that no matter what switches are set internally or externally
cannot 
 compete with ldc or gdc.


People benchmark it anyway.



 It is better to slap a message both in the version/help message of the
compiler 
 and on the site that says "don't use dmd for reviewing of performance of D use 
 ldc/gdc instead".


People doing benchmarks do not read the site. That's the whole problem.



 Given this, it is better to simply remove the switch as it fools people into 
 doing unsafe things that give them a very bad day.


People don't develop code using a -release switch. Those spending time coding
in 
D (rather than spending as little time as possible writing a benchmark) will be 
likely to spend time reading what a switch does before using it.

I've been in this business a long time. What people should do and what they do 
do is rarely aligned. People who do comparative benchmarks spend as little time 
as possible benchmarking a language/compiler they are not familiar with.

Have you ever read the descriptions of all the compiler switches on gcc or VC?

Me neither.



 Jul 17



 next sibling parent  DrDread <DrDread cheese.com>  writes:


On Wednesday, 17 July 2024 at 15:51:29 UTC, Walter Bright wrote:

 People doing benchmarks do not read the site. That's the whole 
 problem.


then keep -release and if used just output "use ldc2 to build a 
performant executable" on console instead.



 Jul 17



prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 18/07/2024 3:51 AM, Walter Bright wrote:

 On 7/15/2024 11:20 AM, Richard (Rikki) Andrew Cattermole wrote:

 Right, but it's dmd we are talking about.

 A compiler that no matter what switches are set internally or 
 externally cannot compete with ldc or gdc.


 
 People benchmark it anyway.


And get bad results.

I really need you to understand just how much things have changed, and 
this bit of experience no longer translates to this lesson. I do accept 
and enjoy the history of the switch when it did translate to this lesson 
however!

This is a real benchmark that came from a Go article that made the 
rounds a while ago, here is my version of it with results I just reran:

https://news.ycombinator.com/item?id=39106972

https://www.reddit.com/r/golang/comments/199u7np/from_slow_to_simd_a_go_optimization_story/

```
$ dmd -O -release -Iinterface main.d -run attempt.d
27033600000     12 secs, 689 ms, 420 ╬╝s, and 5 hnsecs

$ dmd -O -release -Iinterface main.d -run attempt2.d
27033600000     15 secs, 764 ms, 182 ╬╝s, and 9 hnsecs

$ ldc2 -O3 -Iinterface main.d -run attempt.d
27033600000     6 secs, 28 ms, 747 μs, and 4 hnsecs

$ ldc2 -O3 -Iinterface main.d -run attempt2.d
27033600000     14 secs, 939 ms, 722 μs, and 3 hnsecs
```

attempt.d is completely naive, attempt2 does an explicit loop unroll 
with static foreach.

If I turn on release for ldc (or swap to .ptr on the slices):

```
$ ldc2 -O3 -release -Iinterface main.d -run attempt.d
27033600000     6 secs, 70 ms, 191 μs, and 4 hnsecs

$ ldc2 -O3 -release -Iinterface main.d -run attempt2.d
27033600000     5 hnsecs
```

Dmd simply does not have the optimizations to get anywhere close to a 
modern backend. It _cannot_ come close to winning benchmarks.

Note: attempt2 with the second optimization is as good as hand rolled 
assembly by the author of the article.


 It is better to slap a message both in the version/help message of the 
 compiler and on the site that says "don't use dmd for reviewing of 
 performance of D use ldc/gdc instead".


 
 People doing benchmarks do not read the site. That's the whole problem.


And D goes to the bottom of the benchmark.

Except in cases where the D community takes over, like here:

https://github.com/jinyus/related_post_gen/tree/main

A lot of effort went into that by quite a few people.

If anything all of this is making me go: "drop dmd from download page". 
Problem solved.


 Given this, it is better to simply remove the switch as it fools 
 people into doing unsafe things that give them a very bad day.


 
 People don't develop code using a -release switch. Those spending time 
 coding in D (rather than spending as little time as possible writing a 
 benchmark) will be likely to spend time reading what a switch does 
 before using it.


They don't.

We the community catch it and tell them not to use it.

Repeatedly over the last 12 years it has been a very common occurrence.

This is a lesson that has been learned by many people and keeps coming 
up as not what they wanted to use.


 I've been in this business a long time. What people should do and what 
 they do do is rarely aligned. People who do comparative benchmarks spend 
 as little time as possible benchmarking a language/compiler they are not 
 familiar with.


Yes that is what happened in the past, I agree it's a good story for 
showing how things use to be. For benchmarks that make the rounds today 
that isn't what happens.

I linked two different benchmarks that did make the rounds in the last 
year. One was benchmarking Go's backend, the other accepted 
contributions and we won because we could drive LLVM better.

Neither was benchmarking the frontend or language itself.



 Jul 17



 next sibling parent reply Lance Bachmeier <no spam.net>  writes:


On Wednesday, 17 July 2024 at 16:53:36 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


 Dmd simply does not have the optimizations to get anywhere 
 close to a modern backend. It _cannot_ come close to winning 
 benchmarks.


This is the only point that matters in this discussion. DMD has a 
confusing switch that enables someone that doesn't use D to run a 
90% suboptimal benchmark instead of a 100% suboptimal benchmark.

DMD compiles quickly and it usually produces code that runs fast 
enough. It should never be used for benchmarking. If -release is 
how you detect someone doing benchmarking, it should fail to 
compile when using that flag.



 Jul 17



  parent reply Mike Shah <mshah.475 gmail.com>  writes:


On Wednesday, 17 July 2024 at 18:29:03 UTC, Lance Bachmeier wrote:

 On Wednesday, 17 July 2024 at 16:53:36 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:


 Dmd simply does not have the optimizations to get anywhere 
 close to a modern backend. It _cannot_ come close to winning 
 benchmarks.


 This is the only point that matters in this discussion. DMD has 
 a confusing switch that enables someone that doesn't use D to 
 run a 90% suboptimal benchmark instead of a 100% suboptimal 
 benchmark.

 DMD compiles quickly and it usually produces code that runs 
 fast enough. It should never be used for benchmarking. If 
 -release is how you detect someone doing benchmarking, it 
 should fail to compile when using that flag.


 From what I see on: https://dlang.org/dmd-linux.html
"-O
Optimize generated code. For fastest executables, compile with 
the -O -release -inline -boundscheck=off switches together."

Indeed, that is probably good enough documentation that I 
understand what to do to generate something fast when the time 
comes. If there are more flags to tick on or off, we should 
probably add them. That said, I think it's worth thinking about 
these flags.

For example -- When I teach about 'build types/software life 
cycle' in my software engineering course, I often talk about 
'debug' vs 'release' builds using those exact terms and with the 
understanding that debug build is 'slow with debugging symbols' 
and a release build is 'fast with no developer debugging checks 
(i.e. no asserts) on' that you give to the public.

I think the tricky thing is perhaps I have to unlearn from my 'C 
and C++ brain' some of the flags.

In my C and C++ brain: "-release" means "gcc -O2 -g0 ..."
In my C and C++ brain: "-debug" means "gcc -Wall -g3 ..."

In my D brain I really need to think about:

In D Debug Build means: "dmd -debug -g" or "dmd -g"
In D Release Candidate to the public: "dmd -O -release -inline 
-boundscheck=0ff ..."

Note: It seems dub documentation has a table otherwise explaining 
the different builds: https://dub.pm/dub-reference/build_settings/


Anyway -- while writing this post, one suggestion is to add a new 
section of documentation on the Command-line Reference titled 
"Common Build Flag Use Cases" which lists what flags are 
recommended for getting the most out of a debug or release build, 
or a build for benchmarking purposes.

I searched 'benchmark' on the wiki and did not immediately find 
this information: 
https://wiki.dlang.org/The_D_Programming_Language

Note: At some time I'll make a YouTube video talking about flags 
and builds, I just want to hold off if this thread comes to any 
conclusion :)



 Jul 17



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 7/17/24 21:12, Mike Shah wrote:

 In D Release Candidate to the public: "dmd -O -release -inline 
 -boundscheck=0ff ..."


Well, this is the one with potential buffer overrun exploits, so not 
really fit for consumption by the public.



 Jul 17



  parent reply Mike Shah <mshah.475 gmail.com>  writes:


On Wednesday, 17 July 2024 at 19:21:02 UTC, Timon Gehr wrote:

 On 7/17/24 21:12, Mike Shah wrote:

 In D Release Candidate to the public: "dmd -O -release -inline 
 -boundscheck=0ff ..."


 Well, this is the one with potential buffer overrun exploits, 
 so not really fit for consumption by the public.


The description of 'fastest performance' is precise though 🙂 (and 
what you'd want for a benchmark if measuring maximum possible 
performance even when trading safety).

This is why we probably need some wiki page on best practices for 
builds -- I'll put in my work queue to make a video to explain 
compiler flags in the next few weeks then regardless to help with 
some efforts.



 Jul 17



  parent reply "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Wed, Jul 17, 2024 at 08:25:31PM +0000, Mike Shah via Digitalmars-d wrote:

 On Wednesday, 17 July 2024 at 19:21:02 UTC, Timon Gehr wrote:

 On 7/17/24 21:12, Mike Shah wrote:

 In D Release Candidate to the public: "dmd -O -release -inline
 -boundscheck=0ff ..."


 
 Well, this is the one with potential buffer overrun exploits, so not
 really fit for consumption by the public.


 
 The description of 'fastest performance' is precise though 🙂 (and
 what you'd want for a benchmark if measuring maximum possible
 performance even when trading safety).
 
 This is why we probably need some wiki page on best practices for
 builds -- I'll put in my work queue to make a video to explain
 compiler flags in the next few weeks then regardless to help with some
 efforts.


Seriously, if you guys wanna be serious about -release actually doing
something useful, make it run `ldc -O2`.  I'm dead serious.  IME no
amount of -release, -inline, -O with dmd gives me anywhere near
satisfactory performance.  If any of my coworkers were to use dmd and
try to benchmark it with -release, they'd laugh D out of the room.  Make
it run `ldc -O2`, however, and you might actually raise a few eyebrows.

I know it's not nice to admit that dmd does not generate optimal
executables.  I wish I could say otherwise, but the facts are the facts.
I've consistently gotten 30% performance boosts in my program just by
compiling with ldc2 instead of dmd (not even with -O2, just plain ldc2
is enough to give you a significant boost). With ldc2 -O2, I get about
40% performance boost, sometimes up to 50% depending on what the program
does.  If you're trying to win benchmarks, having people use dmd is the
sure way NOT to win them.  You want them to use ldc2, period. You do NOT
want them to use dmd, except when you're trying to compete in the
compile-speed category.

Say what you may about Adam Ruppe and his fork, but he got this one
thing right: have normal dev builds use dmd for compile speeds, and
-release drop dmd altogether and compile with ldc2 instead. This is what
will give newcomers and benchmarkers the best impression of D.

Trying to hack dmd -release to do this or not do that, all of that is
futile, wasted effort. Just ship ldc2 with dmd by default, and have dmd
-release redirect itself to ldc2.  End of story.

(If you don't believe any of the above, don't take my word for it, test
it for yourself. Take any benchmark you wish, compile it with dmd
-release, or dmd -release -O -inline, or any combination of flags you
wish in dmd, really. Run it and save the results.  Now recompile it with
ldc2 -O2.  Compare the results.  The facts speak for themselves.)


T

-- 
Famous last words: I *think* this will work...



 Jul 17



  parent reply Quirin Schroll <qs.il.paperinik gmail.com>  writes:


On Wednesday, 17 July 2024 at 21:19:31 UTC, H. S. Teoh wrote:

 I know it's not nice to admit that dmd does not generate 
 optimal executables.  I wish I could say otherwise, but the 
 facts are the facts. I've consistently gotten 30% performance 
 boosts in my program just by compiling with ldc2 instead of dmd 
 (not even with -O2, just plain ldc2 is enough to give you a 
 significant boost). With ldc2 -O2, I get about 40% performance 
 boost, sometimes up to 50% depending on what the program does.  
 If you're trying to win benchmarks, having people use dmd is 
 the sure way NOT to win them.  You want them to use ldc2, 
 period. You do NOT want them to use dmd, except when you're 
 trying to compete in the compile-speed category.


If that is true, DMD should focus on development and debugging 
experience. The difference between those is small: Essentially, 
the `-debug` switch enables `debug` blocks and possibly 
sacrifices compile-speed for a possibly better debugging 
experience. One would use `-debug` to hunt down a reasonably 
concrete bug. One uses plain `dmd` for feature development, which 
optimizes compile-speed. Even if DMD only had the fastest Code → 
Executable, it has its niche. If it can additionally provide a 
great debugging experience, even better. But we, the D community, 
must be honest with ourselves and not waste time on a lost cause, 
such as getting DMD close to LDC (or GDC, i.d.k. how fast GDC’s 
optimized executables are) in terms of optimizing for fast 
executables.

Free software compilers for the same language may seem like 
competition, but they’re more like members of a team with 
similar, but different-priority roles.



 Jul 17



  parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Wed, Jul 17, 2024 at 11:56:44PM +0000, Quirin Schroll via Digitalmars-d
wrote:

 On Wednesday, 17 July 2024 at 21:19:31 UTC, H. S. Teoh wrote:

 I know it's not nice to admit that dmd does not generate optimal
 executables.  I wish I could say otherwise, but the facts are the
 facts.  I've consistently gotten 30% performance boosts in my
 program just by compiling with ldc2 instead of dmd (not even with
 -O2, just plain ldc2 is enough to give you a significant boost).
 With ldc2 -O2, I get about 40% performance boost, sometimes up to
 50% depending on what the program does.  If you're trying to win
 benchmarks, having people use dmd is the sure way NOT to win them.
 You want them to use ldc2, period. You do NOT want them to use dmd,
 except when you're trying to compete in the compile-speed category.


 
 If that is true, DMD should focus on development and debugging
 experience.


[...]

Don't take my word for it.  Measure it yourself.  Take any D benchmark
and compile with dmd -release -O -inline, then compile with ldc2 -O2.
Compare the difference.  You'll see.


T

-- 
When you breathe, you inspire. When you don't, you expire. -- The Weekly Reader



 Jul 17



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


It's great that the community steps up to ensure we get good benchmark results!

Lots of times benchmarks are done informally and internally by companies, and
we 
never know about them and never have a chance.



 Jul 17



prev sibling  parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Wednesday, July 17, 2024 9:51:29 AM MDT Walter Bright via Digitalmars-d 
wrote:

 On 7/15/2024 11:20 AM, Richard (Rikki) Andrew Cattermole wrote:

 Right, but it's dmd we are talking about.

 A compiler that no matter what switches are set internally or externally
 cannot compete with ldc or gdc.


 People benchmark it anyway.


 It is better to slap a message both in the version/help message of the
 compiler and on the site that says "don't use dmd for reviewing of
 performance of D use ldc/gdc instead".


 People doing benchmarks do not read the site. That's the whole problem.


 Given this, it is better to simply remove the switch as it fools people
 into doing unsafe things that give them a very bad day.


 People don't develop code using a -release switch. Those spending time
 coding in D (rather than spending as little time as possible writing a
 benchmark) will be likely to spend time reading what a switch does before
 using it.

 I've been in this business a long time. What people should do and what they
 do do is rarely aligned. People who do comparative benchmarks spend as
 little time as possible benchmarking a language/compiler they are not
 familiar with.

 Have you ever read the descriptions of all the compiler switches on gcc or
 VC?

 Me neither.


While your approach here might make good sense if -release actually provided
an optimized build, it really doesn't. While it will help somewhat with
giving more performant code, since it does strip out some code, it doesn't
include any actual optimization passes, meaning that it's really not going
to make dmd look much better in benchmarks. Maybe if it included -O, it
would help in the way that you're looking for, but as things stand, I don't
think that it really does. Rather, in practice, what happens is that a
number of programmers assume that -release is what they're supposed to use
for release builds, and that's what they use it for. Folks who are are more
involved with D and/or who use it professionally are more likely to have
taken the time to figure out exactly which switches they want to be using,
but a lot of programmers won't, and dub is set up to use -release as part of
its default release target, meaning that D programmers in general are going
to get it unless they go to extra effort to avoid it (which is obviously an
issue with dub and not the compiler, but it goes to show that whoever made
that choice thought that -release was for release builds, and it affects
everyone using dub).

Regardless, arguably, the main problem here is that -release turns off
bounds checking for non- safe code, and in practice, that's a _lot_ of D
code. It's that behavior that sometimes causes folks like Steven to tell
people to not use -release. The fact that assertions and contracts are
removed is probably just fine, particularly since that's usually what folks
are looking for with a release build, whereas arguably, removing those
bounds checks is enough of an  safety issue that it shouldn't be happening
without the programmer explicitly asking for it (and lumping it into a
switch that does a bunch of other stuff makes it very easy to ask for it
without intending to). And no, -release doesn't remove _all_ bounds
checking, since  safe code still has bounds checking with -release, but a
_lot_ of code doesn't, since a lot of code isn't  safe. So, we're arguably
providing the wrong defaults with -release right now.

So, I'm not sure that I agree with Steven that we should remove -release
(though I'd certainly be fine with that), but I _do_ think that we should
seriously consider changing exactly what it does if we're going to keep it.

- Jonathan M Davis



 Jul 17



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 7/17/2024 10:52 AM, Jonathan M Davis wrote:

 Maybe if it included -O,


It used to, along with -inline, but as I mentioned earlier at some point that 
was removed. It should be put back.



 Jul 17



prev sibling  parent  Elias (0xEAB) <desisma heidel.beer>  writes:


On Monday, 15 July 2024 at 18:14:39 UTC, Walter Bright wrote:

 On 7/14/2024 1:44 PM, Steven Schveighoffer wrote:

 The biggest problem I have, I guess, is that it's called 
 "release". It fools people into thinking you should use it for 
 released code.


 It's an issue I've run into repeatedly. Reviewers not familiar 
 with a compiler look for a "release" switch for benchmarking.


So…
How about calling it -benchmark?



 Jul 18



prev sibling  parent  Sergey <kornburn yandex.ru>  writes:


On Sunday, 14 July 2024 at 20:44:18 UTC, Steven Schveighoffer 
wrote:

 On Saturday, 13 July 2024 at 15:28:36 UTC, Vladimir Panteleev 
 The biggest problem I have, I guess, is that it's called 
 "release". It fools people into thinking you should use it for 
 released code.

 -Steve


But it seems it is not fooling, but it is exactly what dmd devs 
expects from release..
So I think this is what should be alligned



 Jul 17



prev sibling next sibling parent reply Kapendev <alexandroskapretsos gmail.com>  writes:


On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.

 I think we should remove it. If you want no bounds checks, you 
 should have to really want it enough to type that whole 
 monstrosity in. It's trivial to avoid bounds checks by using 
 `.ptr[index]` in ` system` code. In my dub projects, I rewrite 
 the release mode to keep bounds checks for all code, it's that 
 important.

 What do you think? Deprecate for 3 versions, then remove.

 -Steve


I don't really care about this, but some projects might depend on 
it for some reason.
Is it a problem if it just exists? Looks like a simple thing to 
maintain.



 Jul 13



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 7/13/24 19:12, Kapendev wrote:

 On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly -inline`.

 I think we should remove it. If you want no bounds checks, you should 
 have to really want it enough to type that whole monstrosity in. It's 
 trivial to avoid bounds checks by using `.ptr[index]` in ` system` 
 code. In my dub projects, I rewrite the release mode to keep bounds 
 checks for all code, it's that important.

 What do you think? Deprecate for 3 versions, then remove.

 -Steve


 
 I don't really care about this, but some projects might depend on it for 
 some reason.
 Is it a problem if it just exists? Looks like a simple thing to maintain.


It's misleading. It should not be used for creating binary releases. It 
also undercuts D's memory safety aspirations.



 Jul 13



  parent  harakim <harakim gmail.com>  writes:


On Saturday, 13 July 2024 at 21:13:02 UTC, Timon Gehr wrote:

 On 7/13/24 19:12, Kapendev wrote:

 On Saturday, 13 July 2024 at 01:55:16 UTC, Steven 
 Schveighoffer wrote:

 The `-release` flag is equivalent to `-O 
 -boundscheck=safeonly -inline`.

 I think we should remove it. If you want no bounds checks, 
 you should have to really want it enough to type that whole 
 monstrosity in. It's trivial to avoid bounds checks by using 
 `.ptr[index]` in ` system` code. In my dub projects, I 
 rewrite the release mode to keep bounds checks for all code, 
 it's that important.

 What do you think? Deprecate for 3 versions, then remove.

 -Steve






If it's needed for benchmarks but not desired for release code, 
change it to -fast or something. I would hope that someone 
running benchmarks would at least look at the options and see 
that.



 Jul 13



prev sibling next sibling parent  Dukc <ajieskola gmail.com>  writes:


Steven Schveighoffer kirjoitti 13.7.2024 klo 4.55:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly -inline`.
 
 I think we should remove it. If you want no bounds checks, you should 
 have to really want it enough to type that whole monstrosity in. It's 
 trivial to avoid bounds checks by using `.ptr[index]` in ` system` code. 
 In my dub projects, I rewrite the release mode to keep bounds checks for 
 all code, it's that important.
 
 What do you think? Deprecate for 3 versions, then remove.
 
 -Steve


Agree. ` safe` ought to mean no undefined behaviour absent compiler bugs 
or ` trusted` abuse, that should be the default even in release mode.

For the same reason, I also think `-release` shouldn't imply 
`-check=assert=off`, as long as the spec says that is undefined 
behaviour (and dmd doesn't explicitly guarantee not optimising based on 
that).

Maybe I'd go with a longer deprecation period though, like ten releases 
or so.



 Jul 14



prev sibling  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On Saturday, 13 July 2024 at 01:55:16 UTC, Steven Schveighoffer 
wrote:

 The `-release` flag is equivalent to `-O -boundscheck=safeonly 
 -inline`.

 I think we should remove it. If you want no bounds checks, you 
 should have to really want it enough to type that whole 
 monstrosity in. It's trivial to avoid bounds checks by using 
 `.ptr[index]` in ` system` code. In my dub projects, I rewrite 
 the release mode to keep bounds checks for all code, it's that 
 important.

 What do you think? Deprecate for 3 versions, then remove.


OK, so after reading all the pushback from Walter, which is 
completely missing the point, let's go around!

Let's remove --release from ldc. That's the only compiler anyone 
cares about to release with. Even dmd ships built with ldc.

https://github.com/ldc-developers/ldc/issues/4709

-Steve



 Jul 17