This is one of those aspects of memory management that you will rarely have to care about unless performance is a strict requirement. Due to data access latency between memory and the processor, when the processor accesses data from memory, it does so in a chunk and not byte by byte. This is to help reduce the number of memory accesses. This chunk size is called the memory access granularity of the CPU. Usually, the chunk sizes are one word (32 bit), two word, four word, and so on, and they depend on the target architecture. Due to this access granularity, it is desired that the data resides in memory which is aligned to a multiple of the word size. If that is not the case, then the CPU has to read and then perform left or right shifts on the data bits and discard the unneeded data to read a particular value. This wastes CPU cycles. In most cases, the compiler is smart enough to figure out the data alignment for us, but in some cases, we need to tell it. There are two important terms we need to understand:

• Word size: Word size means the number of bits of data processed by the microprocessor as a unit.
• Memory access granularity: The minimum chunk of data accessed by the CPU from the memory bus is called the memory access granularity.

Data types in all programming languages have both a size and an alignment. The alignment of primitive types is equal to their size. So, usually, all primitive types are aligned and the CPU has no problem doing an aligned read for these. But when we create custom data types, compilers usually insert padding between our struct fields if they are not aligned to allow the CPU to access memory in an aligned manner.

Having known about data type size and alignment, let's explore the std::mem module from the standard library that allows us to introspect data types and their sizes.