Variable size and CPU performance

Question

When you learn programming they tell you choose data types that suffice for the concepts you're expressing, i.e. not too small because then your data won't fit and not too big because you don't want nonsensical values stored.

Table of unsigned integers

• 8-bit: 0 to 255
• 16-bit: 0 to 65,535
• 32-bit: 0 to 4,294,967,295
• 64-bit: 0 to 18,446,744,073,709,551,615

According to the table above, an 8-bit unsigned integers can store e.g. the number of weeks in a year (approximately 52) and a 64-bit unsigned integer can store e.g. astronomical values.

To get to the point of my question; how do the different variable sizes affect the performance of a program? I imagine that a 64-bit CPU internally handles all variables as 64-bit and simply ignores the highest bits, so an 8-bit variable, travelling across the system, would be handled as:

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx yyyyyyyy

Where y is either 0/1 and x is ignored.

Would it make any difference performance-wise to only use the largest variable size on the platform and use business logic to enforce reasonableness in the values being processed and stored? Is there a performance hit when using variable sizes lower than the native variable size of the architecture?

Answer 1

Would it make any difference performance-wise to only use the largest variable size on the platform and use business logic to enforce reasonableness in the values being processed and stored?

Yes, it could make your performance worse.

Memory, memory bandwidth, cache density are primary concerns. Larger data size can:

• result in increased cache and translation lookaside buffer (TLB) misses;
• require more RAM to avoid paging.

E.g. x86 CPUs always load (if not already in cache) a whole cache line from memory.

So, assuming a cache line of 64 bytes, there are 64 8-bit-integers per cache line, yet only eight 64-bit-integers. Thus resulting in eight times as many memory transfers for processing a large array.

Also consider that many compiler are smart enough to figure out how to perform automatic vectorization¹.

Taking advantage of the processor's SIMD capabilities you can pack eight 16-bit integers into the same space as two 64-bit integers and do four times as many operations at once.

Is there a performance hit when using variable sizes lower than the native variable size of the architecture?

There isn't a general rule.

x86 CPUs can operate on fractions of a register and there will be no slow down at all².

Other CPUs (e.g. PowerPC) cannot process a fraction of a register. So performing multiple operations on small integers may require masking / cutting back partial results. Anyway it's just a simple AND operation and often the compiler can find a way to avoid it entirely.

As a corner case some instructions can be slower when performed with the CPU's "native size" (e.g. multiplication / division of 64-bit quantities vs 32-bit quantities on Intel Pentium IV).

---

Interesting readings are:

• What Every Programmer Should Know About Memory by Ulrich Drepper (chapter 6, about maximizing the efficiency of the data cache)
• int vs long long in 64 bit machine
• Performance 32 bit vs. 64 bit arithmetic
• The microarchitecture of Intel, AMD and VIA CPUs by Agner Fog

---

1) automatic vectorization is a major research topic in computer science

2) x86 processors can suffer a partial register stall if you, say, write to BX and then try to read from EBX (something to consider mixing integer of different sizes).

Answer 2

I would say it depends on the application and target architecture.

Usually the x86 is the main target, but practices used there might not transfer well into a embedded domain.

Other architectures (usually RISC) have large amount of registers, AVR has 32 registers 8-bits each and it's possible use finer granularity as some instructions have bit wise manipulation.

For example RISC-V has 32 register 32-bit each (or 64-bit or 128-bit depending on the implementation), there the registers are dedicated to pushing arguments between functions without using stack/memory and using a lot of variables might end up being allocated to registers anyway, forcing it to non-native (smaller) size can cause unecesary modulus and other operation to mimic features which now are not given for free by hardware (as there might not be dedicated instruction using smaller type) because the code insists using using smaller type and expects behavior of a smaller type and can't use the native type. So in some cases you will not save on memory size, nor on memory accesses, you will just force CPU to do awkward things because you think it will make it run faster.

When RISC-V has floating point unit implemented then it gets yet another set of registers to work with, so for example rv32-imaf will have 64 registers. So it can really do a lot without touching a stack/memory.