On 3/30/21 1:09 PM, tsbockman wrote:
> On Tuesday, 30 March 2021 at 03:31:05 UTC, Walter Bright wrote:
>> On 3/29/2021 6:29 PM, tsbockman wrote:
>>> On Tuesday, 30 March 2021 at 00:33:13 UTC, Walter Bright wrote:
>>>> Having D generate overflow checks on all adds and multiples will immediately make D uncompetitive with C, C++, Rust, Zig, Nim, etc.
>>>
>>> As someone else shared earlier in this thread, Zig already handles this in pretty much exactly the way I argue for:
>>>     https://ziglang.org/documentation/master/#Integer-Overflow
>>
>> I amend my statement to "immediately make D as uncompetitive as Zig is"
> 
> So you're now dismissing Zig as slow because its feature set surprised you? No real-world data is necessary? No need to understand any of Zig's relevant optimizations or options?

Instead of passing the burden of proof back and forth, some evidence would be welcome. I know nothing about Zig so e.g. I couldn't tell how accurate its claims are: https://news.ycombinator.com/item?id=21117669

FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY

On 3/30/21 7:01 PM, tsbockman wrote:
> Simply flipping compiler switches (the -ftrapv and -fwrapv flags in gcc Andrei mentioned earlier) won't work, because most high performance code contains some deliberate and correct examples of wrapping overflow, signed-unsigned reinterpretation, etc.
> 
> Idiomatic Zig code (probably Ada, too) does contain this information. But, the selection of "real world" open source Zig code available for testing is limited right now, since Zig hasn't stabilized the language or the standard library yet.

That's awfully close to "No true Scotsman".

On 3/30/21 11:07 PM, tsbockman wrote:
> On Wednesday, 31 March 2021 at 01:43:50 UTC, Walter Bright wrote:
>> Thank you for running benchmarks.
>>
>> 14% is a big deal.
> 
> Note that I deliberately chose an integer-intensive workload, and artificially sped up the I/O to highlight the performance cost.

Idea: build dmd with -ftrapv (which is supported, I think, by gdc and ldc) and compare performance. That would be truly interesting.

On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
> FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY

Typing --help in the flags box answers that question :) And the answer is "-O ReleaseFast":
https://godbolt.org/z/1WK6W7TM9

On 3/30/21 11:40 PM, Vladimir Panteleev wrote:
> On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
>> FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY
> 
> Typing --help in the flags box answers that question :) And the answer is "-O ReleaseFast":
> https://godbolt.org/z/1WK6W7TM9

Cool, thanks. I was looking for "the fastest code that still has the checks", how to get that?

On 3/31/21 12:01 AM, Andrei Alexandrescu wrote:
> On 3/30/21 11:40 PM, Vladimir Panteleev wrote:
>> On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
>>> FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY
>>
>> Typing --help in the flags box answers that question :) And the answer is "-O ReleaseFast":
>> https://godbolt.org/z/1WK6W7TM9
> 
> Cool, thanks. I was looking for "the fastest code that still has the checks", how to get that?

I guess that'd be "-O ReleaseSafe":

https://godbolt.org/z/cYcscf1W5

On Wednesday, 31 March 2021 at 04:01:48 UTC, Andrei Alexandrescu wrote:
> On 3/30/21 11:40 PM, Vladimir Panteleev wrote:
>> On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
>>> FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY
>> 
>> Typing --help in the flags box answers that question :) And the answer is "-O ReleaseFast":
>> https://godbolt.org/z/1WK6W7TM9
>
> Cool, thanks. I was looking for "the fastest code that still has the checks", how to get that?

Right, sorry.

--help says:

    ReleaseFast             Optimizations on, safety off
    ReleaseSafe             Optimizations on, safety on

So, maybe that.

The ReleaseSafe code looks pretty good, it generates a "jo" instruction: https://godbolt.org/z/cYcscf1W5

Who knows what it actually looks like in CPU microcode, though :)

On 3/31/21 12:04 AM, Vladimir Panteleev wrote:
> On Wednesday, 31 March 2021 at 04:01:48 UTC, Andrei Alexandrescu wrote:
>> On 3/30/21 11:40 PM, Vladimir Panteleev wrote:
>>> On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
>>>> FWIW I toyed with this but don't know what optimization flags zig takes: https://godbolt.org/z/vKds1c8WY
>>>
>>> Typing --help in the flags box answers that question :) And the answer is "-O ReleaseFast":
>>> https://godbolt.org/z/1WK6W7TM9
>>
>> Cool, thanks. I was looking for "the fastest code that still has the checks", how to get that?
> 
> Right, sorry.
> 
> --help says:
> 
>      ReleaseFast             Optimizations on, safety off
>      ReleaseSafe             Optimizations on, safety on
> 
> So, maybe that.
> 
> The ReleaseSafe code looks pretty good, it generates a "jo" instruction: https://godbolt.org/z/cYcscf1W5
> 
> Who knows what it actually looks like in CPU microcode, though :)

Not much to write home about. The jumps scale linearly with the number of primitive operations:

https://godbolt.org/z/r3sj1T4hc

That's not going to be a speed demon.

On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
> On 3/30/21 1:09 PM, tsbockman wrote:
>> So you're now dismissing Zig as slow because its feature set surprised you? No real-world data is necessary? No need to understand any of Zig's relevant optimizations or options?
>
> Instead of passing the burden of proof back and forth, some evidence would be welcome.

I already posted both some Zig benchmark results of my own, and some C/C++ results from the paper you linked earlier. You just missed them, I guess:

    https://forum.dlang.org/post/ghcnkevthguciupexeyu@forum.dlang.org
    https://forum.dlang.org/post/rnotyrxmczbdvxtalarf@forum.dlang.org

Oversimplified: the extra time required in these tests ranged from less than 0.1% up to 14%, depending on the application.

Also, the Zig checked binaries are actually slightly smaller than the unchecked binaries for some reason.

On 3/31/21 12:11 AM, tsbockman wrote:
> On Wednesday, 31 March 2021 at 03:30:00 UTC, Andrei Alexandrescu wrote:
>> On 3/30/21 1:09 PM, tsbockman wrote:
>>> So you're now dismissing Zig as slow because its feature set surprised you? No real-world data is necessary? No need to understand any of Zig's relevant optimizations or options?
>>
>> Instead of passing the burden of proof back and forth, some evidence would be welcome.
> 
> I already posted both some Zig benchmark results of my own, and some C/C++ results from the paper you linked earlier. You just missed them, I guess:
> 
> https://forum.dlang.org/post/ghcnkevthguciupexeyu@forum.dlang.org
> https://forum.dlang.org/post/rnotyrxmczbdvxtalarf@forum.dlang.org
> 
> Oversimplified: the extra time required in these tests ranged from less than 0.1% up to 14%, depending on the application.

Thanks. This is in line with expectations.

> Also, the Zig checked binaries are actually slightly smaller than the unchecked binaries for some reason.

That's surprising so some investigation would be in order. From what I tried on godbolt the generated code is strictly larger if it uses checks.

FWIW I just tested -fwrapv and -ftrapv. The former does nothing discernible:

https://godbolt.org/z/ErMoeKnxK

The latter generates one function call per primitive operation, which is sure to not win any contests:

https://godbolt.org/z/ahErY3zKn