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

tsbockman thomas.bockman at gmail.com
Wed Mar 31 03:07:23 UTC 2021


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. 
For most real-world applications, the cost is actually *much* 
lower. The paper Andrei linked earlier has a couple of examples:

     Checked Apache httpd is less than 0.1% slower than unchecked.
     Checked OpenSSH file copy is about 7% slower than unchecked.

https://dl.acm.org/doi/abs/10.1145/2743019

> 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.

Only if you choose to disable it. Just because you think it's not 
worth the cost doesn't mean everyone, or even most people, would 
turn it off.

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

It's an admission that it's too expensive *for some 
applications*, not in general. D's garbage collector is too 
expensive for some applications, but that doesn't mean it should 
be removed from the language, nor even disabled by default.

> 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.

That's exactly how checked arithmetic, bounds checking, etc. 
works in Zig. What do you think the difference is, other than 
your arbitrary assertion that checked arithmetic costs more than 
it's worth?

> I said it would make it uncompetitive.

The mean performance difference between C and C++ in the 
(admittedly casual) comparative benchmarks I cited is 36%. Is C 
uncompetitive with C++? What definition of "uncompetitive" are 
you using?

> 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...

Yes, D is better than C in this respect (among many others).


More information about the Digitalmars-d mailing list