Why is there (practically) no 6-byte integer in common usage?

Question

In Postgres, it used to be quite common to use a 4-byte integer auto field for primary keys, until it started becomming somewhat common to run into the 2147483647 limit of 4-byte integers. Now, it's become somewhat common to start with 8-byte integer primary keys, just to be safe, because the small additional cost helps avoid potentially major issues down the road. But, who will ever have a database with 9223372036854775807 (9 billion billion) rows?

This made me wonder why 6-byte integers weren't really a thing. A signed 6 byte integer could hold something like 140 trillion positive values (right?), and would be highly practical for uses like this (database primary keys).

I found this old post, dating back to 2004, asking about 6-byte integers in C. I also found a number of specific technical questions on StackOverflow related to 6-byte integers, but I couldn't find anything well documented or standardized that either A) suggested that 6-byte integers are a common thing, B) should or might become a thing, or C) can't, for some technical reason, become a thing.

Is there any reason why it wouldn't be a good idea, from a performance, practicality, etc. standpoint to have 6-byte integers? Feel free to think about this question in the limited context of C and/or C++, if it helps it avoid being too abstract.

My gut tells me that wide-spread adoption of 6-byte integers would present some kind of big performance boost / RAM savings for a lot of projects, especially in the ML/AI space, as well as some small performance / RAM / space savings in the database world.

Answer 1

6 byte integers present a couple of issues related to alignment. A 6 byte integer needs to have an alignment of 2 or less. An alignment of 4 or 8 would result in needing 2 packing bytes in arrays, negating any density advantages over 8 byte math in arrays.

This presents a problem with cache lines. Conventionally the alignment is at least as large as the value, to ensure that the value will not cross a cache line boundary. Crossing a cache line boundary significantly increases both the complexity of the hardware to handle the read (it has to split the read into two transactions, one of 2 and one of 4, each of which could fail), and doubles the latency, as that now needs two cache bus/memory bus transactions rather than one.

That cost likely more than outweighs the 25% improvement in memory density you get from packing in additional values. And in situations where this is worthwhile to reduce main memory bandwidth, the cost of unpacking manually then doing the math in 64bits is unlikely to be a bottleneck.

And for situations where you aren't dealing with arrays, its rare to be dealing with enough copies that 6 vs 8 bytes is significant, and latency from single accesses would likely be dominated by the misalignment costs.

Answer 2

There are two separate issues here:

• Memory usage
• Processor support for 6 byte integer math.

These issues are somewhat independent, in that a lot of the time numbers are just shuffled around between variables and data structure (no arithmetic operations are performed on them) so even without processor support a language could be designed to only store integers in 6 bytes (inside structures), for one off variables you could still use 8 bytes and use 8 byte arithmetic functions (although you might need extra code for overflow conditions).

If you add 6 byte math support to the processor it would likely have a significant impact on the design of the processor as there would need to be additional instructions added to the processor and this may have downstream effects on other parts of the processor (for example cache lines). I doubt there is a significant enough ROI (extra cost of both design and manufacturing) to justify the extra complexity, given the potential for slightly fast execution of code, even assuming a perfect implementation you are only going to gain a 33% improvement (6 vs 8 bytes moved) in performance for the cases that can benefit from it.

I would also question how much we as programmers want to think about different sizes of integers (premature optimization argument), in that I usually just use Int (32 bit) ** even if byte or short might work, I typically only switch to long for really big numbers or byte if I am processing binary data.

** - I would consider short or byte, if I am storing a lot of them (i.e. allocate a large array of short).

Answer 3

The other answers about the convenience of power-of-two sizes being simpler for addressing are undoubtedly correct, but it's perhaps worth pointing out that there are 6-byte integers in common use, for some value of "common".

Specifically, IEEE 802 MAC address are 6 bytes, which means 6-byte values are used on every Ethernet and Wi-fi packet in the world.

Non-standard (ie, non power-of-two) sizes are always possible. It's just that they're preferred in situations where space is more important than simplicity. It's also relevant that although these really are integer values, they are mostly not used for integer arithmetic.

Answer 4

It’s historical. When hardware manufacturers could improve on 32 bit numbers, they checked that 64 bit was more of a long term solution and easier to implement. For example array indexing can be done by shifting the Index by three bit positions instead of using a multiplication by 6. 8 bytes can be simulated by using 2x4 bytes.

There’s not much difference but some, and you don’t want both 48 and 64 it hardware. Which means 48 bits makes you fall behind the competition.