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: 
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.
Maybe in some cases, signed integers force the compiler to sign-extend them.  

If you move an integer to `eax`, then the high bits of `rax` are set to zeros (the low bits are the bits of `eax`). If it's an integer, you need to set the high 32 bits to the sign of the low 32 bits. It's one extra instruction.

I'm not sure this sign extension is needed in a simple `for (i=0; i<MAX; i++)`.