> > the article complains that unsigned integer overflow is defined in C while signed integer overflow is not.
> The article complains that signed integer overflow is undefined, while unsigned integer overflow is not. There's a difference.
You are correct.
> > the Clang team believes this makes loops up to 20% faster
> I'd love to see the benchmarks they conducted.
It wouldn’t surprise me if they have micro benchmarks. I convinced myself they were telling the truth based on crude instruction counting: a loop must be converted into something like:
- loop body (assume it contains at least one machine instruction)
- increment loop variable
- (for unsigned): clear overflow flag
- test loop variable, exit loop if appropriate
- goto beginning of loop
I believe they don’t have to actually check the overflow flag, it’s OK to let the overflow happen. But they do have to clear the flag to avoid a spurious error if the flag gets looked at later.
I’m no expert, so it’s possible this oversimplifies things, but removing the instruction to clear the flag does remove a big chunk of this loop. But it’s a big chunk only because it’s a tight loop.
For the record, I happily use the foreach loop constructs in C++, D, Java, C#, Python, Perl, etc. but I originally avoided them until I saw a comment by Walter Bright that there is no performance penalty in D (the compiler rewrites the loop appropriately; there may be a penalty in Java because the feature might be defined in terms of their relatively heavy iterators).
> The article complains that signed integer overflow is undefined, while unsigned integer overflow is not. There's a difference.
You are correct.
> > the Clang team believes this makes loops up to 20% faster
> I'd love to see the benchmarks they conducted.
It wouldn’t surprise me if they have micro benchmarks. I convinced myself they were telling the truth based on crude instruction counting: a loop must be converted into something like:
- loop body (assume it contains at least one machine instruction)
- increment loop variable
- (for unsigned): clear overflow flag
- test loop variable, exit loop if appropriate
- goto beginning of loop
I believe they don’t have to actually check the overflow flag, it’s OK to let the overflow happen. But they do have to clear the flag to avoid a spurious error if the flag gets looked at later.
I’m no expert, so it’s possible this oversimplifies things, but removing the instruction to clear the flag does remove a big chunk of this loop. But it’s a big chunk only because it’s a tight loop.
For the record, I happily use the foreach loop constructs in C++, D, Java, C#, Python, Perl, etc. but I originally avoided them until I saw a comment by Walter Bright that there is no performance penalty in D (the compiler rewrites the loop appropriately; there may be a penalty in Java because the feature might be defined in terms of their relatively heavy iterators).