4 ms·
Its not about the size, its about the signedness being presumably not natural for an index, and the potential for having very inconvenient consequences for perf
by msbarnett 5y ago
Its not about the size, its about the signedness being presumably not natural for an index, and the potential for having very inconvenient consequences for performance on modern CPU architectures if you were not able to assume the index never goes negative due to a wrap.
Basically, to get decent perf out of C loops, arithmetic overflow has to be left as UB for int. If the standard index variable type had historically been unsigned and defined to terminate on overflow or something, you could make wrap-on-overflow standard for int without killing the performance of hot inner loops.
- saurik 5y agoNo: the killer issue is the size. The loop index going negetive doesn't affect the performance at all, but making sure that it actually wraps at 32-bits instead of 64-bits requires simulating the 32-bit wrapping with a clamp.
- msbarnett 5y agoloop optimization is intimately tied to being able to assume the index doesn't wrap and exit the array, no? GCC says: > -faggressive-loop-optimizations This option tells the loop optimizer to use language constraints to derive bounds for the number of iterations of a loop. This assumes that loop code does not invoke undefined behavior by for example causing signed integer overflows or out-of-bound array accesses. The bounds for the number of iterations of a loop are used to guide loop unrolling and peeling and loop exit test optimizations.