3 ms·

> minority use-case The amount of code that looks like this in a big enough hot loop to make a difference is negligible. Can you provide even one real-world ex

> minority use-case The amount of code that looks like this in a big enough hot loop to make a difference is negligible. Can you provide even one real-world example where this makes a difference, i.e. not some microbenchmark? The amount of code that can break as a result of signed overflows being UB, on the other hand, is huge. > programmers would have to do a lot more fragile hand-unrolling of operations to get that performance back Much easier ways to do this, e.g. by using an assert wrapper around __builtin_unreachable. Alternatively, an unsafe_int_t could be defined that gives the optimize-able behavior. The important thing is to make it opt-in; sensible defaults matter.

msbarnett 5y ago
> Can you provide even one real-world example where this makes a difference, i.e. not some microbenchmark Sure. I don't even have to leave this thread to find one: https://news.ycombinator.com/item?id=27223954 https://news.ycombinator.com/item?id=27223954 reports a measurable speed impact to PostgreSQL when compiled with -fwrapv, which rules out the exact optimization in question. This shouldn't be surprising; loops are extremely common and superscalar processors benefit enormously from almost anything other than a naïve translation of them. Here's -fwrapv cutting performance of a function in half in Cython vs the non-fwrapv compilation: https://stackoverflow.com/questions/46496295/poor-performance-of-c-function-in-cython https://stackoverflow.com/questions/46496295/poor-performanc...
- vyodaiken 5y ago
  Sure, if you leave out error checks code runs faster. Compile mutexes to no-ops and get an even better speedup.
  - msbarnett 5y ago
    The optimizations impacted by -fwrapv have nothing whatsoever to do with “leaving out error checks”
    - vyodaiken 5y ago
      I don't know how you can say that z = x+y; if(z< x )overflowerror(); //important computation and for(i=start, i >= start && i < n; i++)docomputation(x[i]); etc.
MauranKilom 5y ago
> The amount of code that can break as a result of signed overflows being UB, on the other hand, is huge C++ recently decided to not make signed overflow defined, despite having the explicit opportunity to do so. Here is the reasoning: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html#r0r1 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090... > Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs; > Implementation leeway for tools such as sanitizers; > Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug. Presumably, data from Google disproves your assertion that the amount of code that breaks due to signed overflow being UB is huge.

msbarnett 5y ago

> Can you provide even one real-world example where this makes a difference, i.e. not some microbenchmark Sure. I don't even have to leave this thread to find one: https://news.ycombinator.com/item?id=27223954 https://news.ycombinator.com/item?id=27223954 reports a measurable speed impact to PostgreSQL when compiled with -fwrapv, which rules out the exact optimization in question. This shouldn't be surprising; loops are extremely common and superscalar processors benefit enormously from almost anything other than a naïve translation of them. Here's -fwrapv cutting performance of a function in half in Cython vs the non-fwrapv compilation: https://stackoverflow.com/questions/46496295/poor-performance-of-c-function-in-cython https://stackoverflow.com/questions/46496295/poor-performanc...

vyodaiken 5y ago
Sure, if you leave out error checks code runs faster. Compile mutexes to no-ops and get an even better speedup.
- msbarnett 5y ago
  The optimizations impacted by -fwrapv have nothing whatsoever to do with “leaving out error checks”
  - vyodaiken 5y ago
    I don't know how you can say that z = x+y; if(z< x )overflowerror(); //important computation and for(i=start, i >= start && i < n; i++)docomputation(x[i]); etc.

MauranKilom 5y ago

> The amount of code that can break as a result of signed overflows being UB, on the other hand, is huge C++ recently decided to not make signed overflow defined, despite having the explicit opportunity to do so. Here is the reasoning: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html#r0r1 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090... > Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs; > Implementation leeway for tools such as sanitizers; > Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug. Presumably, data from Google disproves your assertion that the amount of code that breaks due to signed overflow being UB is huge.