3 ms·

There was a talk about UB that proved to me there is no way out of this UB box for C++. Specifically how calculating an int aka signed 32 bit integer index was

There was a talk about UB that proved to me there is no way out of this UB box for C++. Specifically how calculating an int aka signed 32 bit integer index was more performent than calculating a uint aka unsigned 32 bit integer index. Because the former because an assembly intrinsic and the later can't because uint wraps at 32 bits not 64 bits. So whether you choose wrapping or UB you are going to piss somebody off. After all everybody wants the intrinsic. After all you are triggering UB anywhere the wrapping matters.

variadix 3y ago
Or just use size_t like was mentioned in that talk.
- Guvante 3y ago
  Certainly you can refactor your code to avoid performance pitfalls but that is effectively always true for large programs... The reality is the number of similar UB based optimisations has grown considerably and even divesting of them would involve likely close to a man-decade worth of effort (unless you just discarded all of those performance improvements).
spc476 3y ago
I'm not following you here. Most systems (if not all) are byte-addressable 2's complement systems, and in a 2's complement system, you use the same instructions for math for both signed and unsigned integers. Compiler writers aren't using different instructions for signed vs. unsigned, they're using different assumptions about interpretations, along the lines of "if X is signed, then x = x + 1 will never wrap, because that is UB, and as we all know, programmers will never intentionally or unintentionally, invoke UB, so we can skip some checks and if the program blows up, it's the programmers fault for not being perfect."
- UncleMeat 3y ago
  Depends on the target. If you have a 32 bit unsigned integer and your hardware wraps at 64 bit, you need special logic to wrap correctly at 32 bits. This also can prevent some vectorization since you don't have the guarantee that the result of x + 1 is one larger than x.
pjmlp 3y ago
Same applies to C, Objective-C and Objective-C++.

variadix 3y ago

Or just use size_t like was mentioned in that talk.

Guvante 3y ago
Certainly you can refactor your code to avoid performance pitfalls but that is effectively always true for large programs... The reality is the number of similar UB based optimisations has grown considerably and even divesting of them would involve likely close to a man-decade worth of effort (unless you just discarded all of those performance improvements).

spc476 3y ago

I'm not following you here. Most systems (if not all) are byte-addressable 2's complement systems, and in a 2's complement system, you use the same instructions for math for both signed and unsigned integers. Compiler writers aren't using different instructions for signed vs. unsigned, they're using different assumptions about interpretations, along the lines of "if X is signed, then x = x + 1 will never wrap, because that is UB, and as we all know, programmers will never intentionally or unintentionally, invoke UB, so we can skip some checks and if the program blows up, it's the programmers fault for not being perfect."

UncleMeat 3y ago
Depends on the target. If you have a 32 bit unsigned integer and your hardware wraps at 64 bit, you need special logic to wrap correctly at 32 bits. This also can prevent some vectorization since you don't have the guarantee that the result of x + 1 is one larger than x.

pjmlp 3y ago

Same applies to C, Objective-C and Objective-C++.