Time to move std.experimental.checkedint to std.checkedint ?

[Walter Bright]

On 3/30/2021 4:01 PM, tsbockman wrote:
> So, in this particular task ReleaseSafe (which checks for a lot of other things, 
> not just integer overflow) takes 14% longer than ReleaseFast. If you only care 
> about user time, that is 48% longer.

Thank you for running benchmarks.

14% is a big deal.

> Last time I checked, these numbers are similar to the performance difference 
> between optimized builds by DMD and LDC/GDC. They are also similar to the 
> performance differences within related language pairs like C/C++, Java/C#, Ada/C 
> in language comparison benchmarks like:
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/cpp.html
> 
> Note also that with Zig's approach, paying the modest performance penalty for 
> the various safety checks is *completely optional* in release builds (just like 
> D's bounds checking). Even for applications where that final binary order of 
> magnitude of speed is considered essential in production, Zig's approach still 
> leads to clearer, easier to debug code.

The problem with turning it off for production code is that the overflows tend 
to be rare and not encountered during testing. When you need it, it is disabled.

Essentially, turning it off for release code is an admission that it is too 
expensive.

Note that D's bounds checking is *not* turned off in release mode. It has a 
separate switch to turn that off, and I recommend only using it to see how much 
performance it'll cost for a particular application.

> So, unless DMD (or C itself!) is "a brick" that "won't fly", your claim that 
> this is something that a high performance systems programming language just 
> cannot do is not grounded in reality.

I didn't say cannot. I said it would make it uncompetitive.

Overflow checking would be nice to have. But it is not worth the cost for D. I 
also claim that D code is much less likely to suffer from overflows because of 
the implicit integer promotion rules. Adding two shorts is never going to 
overflow, for example, and D won't let you naively assign the resulting int back 
to a short.

One could legitimately claim that D *does* have a form of integer overflow 
protection in the form of Value Range Propagation (VRP). Best of all, VRP comes 
for free at zero runtime cost!

P.S. I know you know this, due to your good work on VRP :-) but I mention it for 
the other readers.

P.P.S. So why is this claim not made for C? Because:

     short s, t, u;
     s = t + u;

compiles without complaint in C, but will fail to compile in D. C doesn't have VRP.