Yes, caching. 32 bit quantities are often sufficient, and take up less space in cache.
Additionally, code that handles 32-bit registers in x86_64 is often shorter than its 64-bit counterpart due to the lack of REX prefixes in instructions. This also reduces the instruction cache footprint. Some instructions like integer division and multiplication are also faster when handling 32-bit quantities, but this depends on the microarchitecture in question.
"Additionally, code that handles 32-bit registers in x86_64 is often shorter than its 64-bit counterpart due to the lack of REX prefixes in instructions."
Excellent point, thank you. I was only thinking about the data cache. Interestingly, I believe 64-bit ARM (AArch64) instructions are still only 32 bits long though I haven't confirmed via google. Maybe someone can correct me.
AArch64 instructions are still 32 bits long. These slides from the ARMv8 Technology Preview provide a great overview of the ARMv8 architecture:
Re:Three Optimization Tips for C++
by stephencanon on Wednesday May 07, 2014 @08:40PM
(#7713384)
> I believe 64-bit ARM (AArch64) instructions are still only 32 bits long
Correct, but I wouldn’t say “still”, since some “thumb” AArch32 instructions are 16b.
On a meta-note, I'm really happy to see more highly technical submissions like this hitting and sticking on the front page.
EDIT: from the slides:
Prefer 32 bit ints to all other sizes
1. 64 bit may make some code slower [no additional explanation given]
2. 8, 16 bit computation use conversion to 32 bits and back