Memory Hierarchy - Application of The Concept

Application of The Concept

The memory hierarchy in most computers is:

• Processor registers – the fastest possible access (usually 1 CPU cycle), only hundreds of bytes in size
• Level 1 (L1) cache – often accessed in just a few cycles, usually tens of kilobytes
• Level 2 (L2) cache – higher latency than L1 by 2× to 10×, usually has 512 KiB or more
• Level 3 (L3) cache – higher latency than L2, usually has 2048 KiB or more
• Main memory – may take hundreds of cycles, but can be multiple gigabytes. Access times may not be uniform, in the case of a NUMA machine.
• Disk storage – millions of cycles latency if not cached, but can be multiple terabytes
• Tertiary storage – several seconds latency, can be huge

Note that the hobbyist who reads "L1 cache" in the computer specifications sheet is reading about the 'internal' memory hierarchy .

Most modern CPUs are so fast that for most program workloads, the bottleneck is the locality of reference of memory accesses and the efficiency of the caching and memory transfer between different levels of the hierarchy. As a result, the CPU spends much of its time idling, waiting for memory I/O to complete. This is sometimes called the space cost, as a larger memory object is more likely to overflow a small/fast level and require use of a larger/slower level.

Modern programming languages mainly assume two levels of memory, main memory and disk storage, though in assembly language and inline assemblers in languages such as C, registers can be directly accessed. Taking optimal advantage of the memory hierarchy requires the cooperation of programmers, hardware, and compilers (as well as underlying support from the operating system):

• Programmers are responsible for moving data between disk and memory through file I/O.
• Hardware is responsible for moving data between memory and caches.
• Optimizing compilers are responsible for generating code that, when executed, will cause the hardware to use caches and registers efficiently.

Many programmers assume one level of memory. This works fine until the application hits a performance wall. Then the memory hierarchy will be assessed during code refactoring.