It's surprising how often this issue (ceiling for 32-bit ints) comes up way.
If you're still using integers (for ids, timestamps, etc) then just go with 64-bits. It avoids any potential problem with data size in the future, and if the size stays small then it won't matter anyway. Storage is cheap and CPU cache lines are 64-bit now too.
Ah you're right, I was thinking about 64-bit alignment for atomic operations. Either way none of this matters except under the most extreme performance conditions.
Comments
It's surprising how often this issue (ceiling for 32-bit ints) comes up way.
If you're still using integers (for ids, timestamps, etc) then just go with 64-bits. It avoids any potential problem with data size in the future, and if the size stays small then it won't matter anyway. Storage is cheap and CPU cache lines are 64-bit now too.
Cache lines are 64 bytes not bits. That is: a cache line can store 8 64-bit numbers.
Ah you're right, I was thinking about 64-bit alignment for atomic operations. Either way none of this matters except under the most extreme performance conditions.
This will always be a challenge for applications that start their lives as 32-bit (Exchange wasn't 64-bit until 2007)
Thought this had to do with memory addressing/pointer size, not data types.