Question: > 
> **Possible Duplicate:**  
> 
> [performance of unsigned vs signed integers](https://stackoverflow.com/questions/4712315/performance-of-unsigned-vs-signed-integers) 
> 
> 
> 

I have read somewhere that it's a tiny bit faster on `x86_64` to compare `signed ints` in `C/C++` compared to `unsigned ints`, e.g. `for (int i...`) is "faster" than `for (uint i...)`.

Is that true? Why is that true? I know the difference is super small, but anyway.

Answer: 
You'd better cite a source for such a claim, which is ridiculous on the face of it.

We're talking about x86\_64, which means modern processors. These ALUs will complete integer addition, subtraction, and/or comparison in a single clock cycle (cache misses will of course take longer, but depend only on the size and memory layout of the data, not signed-ness). Or even less, with the SIMD coprocessor.

I'd more likely to believe that there's a slight power difference between the two types of comparison, but not a speed difference.

Now, it is possible that for a particular compiler, code generation is worse for one data type vs the other when targeting the x86\_64 platform. But that would be a very specialized case, and not likely to apply to all x86\_64 compilers. And still, I'd suspect cache effects or background processes were affecting the performance measurement (even performance counters that measure time spent per-process will be affected by a context switch invalidating caches).
Well, there's no good answer here. The speed differences are usually going to so be marginal that you get better performance by spending your time thinking about other things. But there are a few weird cases, since signed overflow is undefined. For example, compare these two:

```
for (int i = 0; condition(); ++i) {
    if (i == 0) {
        computation();
    }
}

for (unsigned i = 0; condition(); ++i) {
    if (i == 0) {
        computation();
    }
}

```

A conformant compiler can move `computation` outside the loop that uses a signed index because it can assume that `i == 0` once and only once -- because signed overflow is undefined behavior (overflow could terminate the program, or wrap around, or make demons fly out your nose). However, the compiler cannot move `computation` outside the second loop without significantly more work (unsigned integers always wrap around when they overflow).

**However,** on x86\_64 you often have to sign-extend an `int` before working with it. This takes an additional instruction.

**Conclusion:** It's not really important. Whoever told you that one is faster than the other is distracting you from being productive.