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).
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++)`.