On 3/30/2021 9:28 PM, Elronnd wrote:
> Why is this being seriously discussed as a performance pitfall?

1% is a serious improvement. If it wasn't, why would Rust (for example) who likely tried harder than anyone to make it work, still disable it for release code?

On 3/31/2021 7:36 AM, Max Haughton wrote:
> Intel C++ can be a little naughty with the fast math options, last time I checked, for example - gotta get those SPEC numbers!

Benchmarks are always going to be unfair, but it's only reasonable to try and set the switches as close as practical so they are trying to accomplish the same thing.

> Standardizing some kind of `assume` semantics strikes me as a good long term hedge for D, even if doing static analysis and formal verification of D code is an unenviable task.

Static analysis has limits. For example, I complained to Vladimir that using hardcoded loop limits enabled optimizations not available to recommended programming practice of not using hardcoded limits.

On 2021-03-31 13:46, Max Haughton wrote:

> Specific Example? GCC and LLVM are both almost rabid when you turn the vectorizer on

No, that's why I said "can be". But what I meant is that just running the Zig compiler out of the box might produce better code than Clang because it uses different default optimizations. I mean that is a poor way of claiming Zig is faster than C because it's easy to add a couple of flags to Clang and it will probably be the same speed as Zig. They use the same backend anyway.

-- 
/Jacob Carlborg

On Thursday, 1 April 2021 at 00:50:21 UTC, Walter Bright wrote:
> On 3/30/2021 9:28 PM, Elronnd wrote:
>> Why is this being seriously discussed as a performance pitfall?
>
> 1% is a serious improvement. If it wasn't, why would Rust (for example) who likely tried harder than anyone to make it work, still disable it for release code?

That's an appeal to authority.  You haven't actually justified their choice.  (Nor, for that matter, have you justified that 1% is a serious performance improvement.)

On 31.03.21 13:18, Max Samukha wrote:
> On Tuesday, 30 March 2021 at 06:43:04 UTC, Walter Bright wrote:
> 
>>
>> Compile-time isn't a run-time performance issue.
> 
> Performance is irrelevant to the fact that D frivolously violates basic assumptions about float/double at compile-time.

Not just at compile time, but it's less noticeable at runtime because compilers usually choose to do the right thing anyway.

On 4/1/2021 10:59 PM, Elronnd wrote:
> On Thursday, 1 April 2021 at 00:50:21 UTC, Walter Bright wrote:
>> On 3/30/2021 9:28 PM, Elronnd wrote:
>>> Why is this being seriously discussed as a performance pitfall?
>>
>> 1% is a serious improvement. If it wasn't, why would Rust (for example) who likely tried harder than anyone to make it work, still disable it for release code?
> 
> That's an appeal to authority.  You haven't actually justified their choice.  (Nor, for that matter, have you justified that 1% is a serious performance improvement.)

That's backwards. You want other people to invest in this technology, you need to justify it.

I've been in this business for 40 years. I know for a fact that if you're trying to sell a high performance language that is inherently slower than the current one they're using, you've got a huge problem.

Having written high performance apps myself, I'll take 1%. I work on getting a lot smaller gains than that, because they add up.

As for Appeal to Authority, there is more nuance to it than one might think:

"Exception: Be very careful not to confuse "deferring to an authority on the issue" with the appeal to authority fallacy. Remember, a fallacy is an error in reasoning. Dismissing the council of legitimate experts and authorities turns good skepticism into denialism. The appeal to authority is a fallacy in argumentation, but deferring to an authority is a reliable heuristic that we all use virtually every day on issues of relatively little importance. There is always a chance that any authority can be wrong, that’s why the critical thinker accepts facts provisionally. It is not at all unreasonable (or an error in reasoning) to accept information as provisionally true by credible authorities. Of course, the reasonableness is moderated by the claim being made (i.e., how extraordinary, how important) and the authority (how credible, how relevant to the claim)."

https://www.logicallyfallacious.com/logicalfallacies/Appeal-to-Authority

---

I'm not preventing anyone from adding integer overflow detection to D. Feel free to make a prototype and we can all evaluate it.

On Friday, 2 April 2021 at 20:56:04 UTC, Walter Bright wrote:
>
> I'm not preventing anyone from adding integer overflow detection to D. Feel free to make a prototype and we can all evaluate it.

Seems to be a bit like bounds checks (less obvious benefits), it could be made default but disabled in -b release-nobounds

Even while being opt-out, bounds check are annoying in D because with DUB you typically profile a program built with dub -b release-debug and that _includes_ bounds checks! So I routinely profile programs that aren't like the actual output.

So, integer overflow checks would - in practice - further hinder capacity to profile programs.

On Saturday, 3 April 2021 at 09:09:33 UTC, Guillaume Piolat wrote:
> On Friday, 2 April 2021 at 20:56:04 UTC, Walter Bright wrote:
>>
>> I'm not preventing anyone from adding integer overflow detection to D. Feel free to make a prototype and we can all evaluate it.
>
> Seems to be a bit like bounds checks (less obvious benefits), it could be made default but disabled in -b release-nobounds
>
> Even while being opt-out, bounds check are annoying in D because with DUB you typically profile a program built with dub -b release-debug and that _includes_ bounds checks! So I routinely profile programs that aren't like the actual output.
>
> So, integer overflow checks would - in practice - further hinder capacity to profile programs.

It’s not like bounds checks because there’s loads of code out there that correctly uses overflow. It’s a significant breaking change to turn that switch on, not just a “would you like to trade some speed for safety” like bounds-checks are.

That’s not to say it shouldn’t be done. I’m just pointing out that it’s very different.