2018/07/19 by Vinson Young, Sanjay Kariyappa, Young, Vinson +3 · 2 voices
Computer Science · #Parallel Computing and Optimization Techniques #Advanced Data Storage Technologies #Algorithms and Data Compression
paper · pdf · doi:10.48550/arxiv.1807.07685
This paper investigates hardware-based memory compression designs to increase\nthe memory bandwidth. When lines are compressible, the hardware can store\nmultiple lines in a single memory location, and retrieve all these lines in a\nsingle access, thereby increasing the effective memory bandwidth. However,\nrelocating and packing multiple lines together depending on the compressibility\ncauses a line to have multiple possible locations. Therefore, memory\ncompression designs typically require metadata to specify the compressibility\nof the line. Unfortunately, even in the presence of dedicated metadata caches,\nmaintaining and accessing this metadata incurs significant bandwidth overheads\nand can degrade performance by as much as 40%. Ideally, we want to implement\nmemory compression while eliminating the bandwidth overheads of metadata\naccesses.\n This paper proposes CRAM, a bandwidth-efficient design for memory compression\nthat is entirely hardware based and does not require any OS support or changes\nto the memory modules or interfaces. CRAM uses a novel implicit-metadata\nmechanism, whereby the compressibility of the line can be determined by\nscanning the line for a special marker word, eliminating the overheads of\nmetadata access. CRAM is equipped with a low-cost Line Location Predictor (LLP)\nthat can determine the location of the line with 98% accuracy. Furthermore, we\nalso develop a scheme that can dynamically enable or disable compression based\non the bandwidth cost of storing compressed lines and the bandwidth benefits of\nobtaining compressed lines, ensuring no degradation for workloads that do not\nbenefit from compression. Our evaluations, over a diverse set of 27 workloads,\nshow that CRAM provides a speedup of up to 73% (average 6%) without causing\nslowdown for any of the workloads, and consuming a storage overhead of less\nthan 300 bytes at the memory controller.\n