What are the performance difference between unsigned and signed integers?

Question

I am aware of the performance hit when mixing signed ints with floats.

Is it any worse to mix unsigned ints with floats?

Is there any hit when mixing signed/unsigned without floats?

Do the different sizes (u32, u16, u8, i32, i16, i8) have any effect on performance? On which platforms?

Answer 1

The large penalty from mixing ints (of any kind) and floats is because these are in different register sets. To go from one register set to the other, you have to write the value to memory and read it back, which incurs a a load-hit-store stall.

Going between different sizes or signed-ness of ints keeps everything in the same register set, so you avoid the big penalty. There may be smaller penalties due to sign-extensions, etc. but these are much smaller than a load-hit-store.

Answer 2

I suspect that information about the Xbox 360 and PS3 specifically are going to be behind licensed-developer-only walls, like most low-level details. However, we can construct an equivalent x86 program and disassemble it to get a general idea.

First, let's see what unsigned widening costs:

unsigned char x = 1;
unsigned int y = 1;
unsigned int z;
z = x;
z = y;

The relevant portion disassembles into (using GCC 4.4.5):

    z = x;
  27:   0f b6 45 ff             movzbl -0x1(%ebp),%eax
  2b:   89 45 f4                mov    %eax,-0xc(%ebp)
    z = y;
  2e:   8b 45 f8                mov    -0x8(%ebp),%eax
  31:   89 45 f4                mov    %eax,-0xc(%ebp)

So basically the same - in one case we move a byte, in the other we move a word. Next:

signed char x = 1;
signed int y = 1;
signed int z;
z = x;
z = y;

Turns into:

   z = x;
  11:   0f be 45 ff             movsbl -0x1(%ebp),%eax
  15:   89 45 f4                mov    %eax,-0xc(%ebp)
    z = y;
  18:   8b 45 f8                mov    -0x8(%ebp),%eax
  1b:   89 45 f4                mov    %eax,-0xc(%ebp)

So the cost of the sign extension is whatever the cost of movsbl rather than movzbl is - sub-instruction level. That's basically impossible to quantify on modern processors due to the way the modern processors work. Everything else, ranging from memory speed to caching to what was in the pipeline beforehand, is going to dominate the runtime.

In the ~10 minutes it took me to write these tests, I could easily have found a real performance bug, and as soon as I turn on any level of compiler optimization, the code becomes unrecognizable for such straightforward tasks.

This isn't Stack Overflow, so I hope no one here will claim microoptimization doesn't matter. Games often work on data that is very large and very numeric, so careful attention to branching, casts, scheduling, structure alignment, and so on can give very critical improvements. Anyone who has spent a lot of time optimizing PPC code probably has at least one horror story about load-hit-stores. But in this case, it really doesn't matter. The storage size of your integer type doesn't affect performance, as long as it's aligned and fits in a register.

Answer 3

Operations with signed or unsigned int have the same cost on current processors (x86_64, x86, powerpc, arm). On 32bits processor, u32, u16, u8 s32, s16, s8 should be the same. You can have penalty with bad alignement.

But convert int to float or float to int is a costly operation. You can easily find optimized implementation (SSE2, Neon ...).

The most important point is probably memory access. If your data doesn't fit in L1/L2 cache, you will loose more cycle than conversion.

Answer 4

Signed integer operations can be more expensive on nearly all architectures. For example, division by a constant is faster when unsigned, e.g:

unsigned foo(unsigned a) { return a / 1024U; }

is going to be optimized to:

unsigned foo(unsigned a) { return a >> 10; }

But...

int foo(int a) { return a / 1024; }

will optimize to:

int foo(int a) {
  return (a + 1023 * (a < 0)) >> 10;
}

or on systems where branching is cheap,

int foo(int a) {
  if (a >= 0) return a >> 10;
  else return (a + 1023) >> 10;
}

Same goes for modulo. This also holds true for non-powers-of-2 (but the example is more complex). If your architecture doesn't have a hardware divide (e.g most ARM), unsigned divides of non-consts are also quicker.

In general, telling the compiler that negative numbers can't result will aid optimization of expressions, especially those used for loop termination and other conditionals.

As for different size ints, yes there's a slight impact but you'd have to weigh that vs moving less memory around. These days you probably gain more from accessing less memory than you lose from size expansion. You're very far into micro-optimization at that point.

Answer 5

Jon Purdy says above (I can't comment) that unsigned might be slower because it can't overflow. I disagree, unsigned arithmetic is simple moular arithmetic modulo 2 to the number of bits in the word. Signed operations in principle can suffer overflows, but they are usually turned off.

Sometimes you can do clever (but not very readable things) like pack two or more data items into an int, and get multiple operations per instruction (pocket arithmetic). But you gotta understand what you are doing. Of course MMX allows you to do this naturally. But sometimes using the largest HW supported word size and manually packing the data gives you the fastest implementation.

Be careful about data alignment. On most HW implementations nonaligned loads and stores are slower. Natural alignment, means that for say a 4byte word, the address is a multiple of four, and eight byte word addresses should be multiples of eight bytes. This carries over into SSE (128bit favors 16byte alignment). AVX will soon extend these "vector" register sizes to 256bits then 512bits. And aligned loads/stores will be faster than unaligned ones. For HW geeks, an unaligned memory operation may span things like cacheline and even page boundaries, for which the HW has to be careful about.

Answer 6

It is slightly better to use signed integers for loop indexes, because signed overflow is undefined in C, so the compiler will assume that such loops have fewer corner cases. This is controlled by gcc's "-fstrict-overflow" (enabled by default) and the effect is probably hard to notice without reading the assembly output.

Beyond that, x86 works better if you don't mix types, because it can use memory operands. If it has to convert types (sign or zero extensions) that means an explicit load and the use of a register.

Stick with int for local variables and most of this will happen by default.

Answer 7

As celion points out, the overhead of converting between ints and floats has largely to do with the copying and conversion of values between registers. The only overhead of unsigned ints in and of themselves comes from their guaranteed wraparound behaviour, which necessitates a certain amount of overflow checking in the compiled code.

There is basically no overhead in converting between signed and unsigned integers. Different sizes of integer may be (infinitesimally) faster or slower to access depending on platform. Generally speaking, the size of integer that's closest to the word size of the platform will be the fastest to access, but the overall performance difference depends on many other factors, most notably cache size: if you use uint64_t when all you need is uint32_t, it may be that less of your data is going to fit in the cache at once, and you may incur some load overhead.

It's a bit excessive to even think about this, though. If you use types that are appropriate for your data, things ought to work perfectly fine, and the amount of power to be gained by selecting types based on architecture is negligible anyway.