Search papers, labs, and topics across Lattice.
This paper investigates the residual cache state on the Apple M4 Pro after GPU command execution, revealing critical insights into CPU-GPU memory interactions. By employing a synchronized Metal experiment and validating the measurement pipeline against established benchmarks, the authors demonstrate that large GPU workloads significantly slow down subsequent CPU accesses due to cache displacement effects. The findings highlight a reproducible post-GPU cache-displacement window and propose a straightforward recovery mechanism to mitigate performance degradation.
Large GPU workloads can leave a lingering cache state that dramatically impacts CPU performance, but a simple recovery mechanism can alleviate this issue.
Apple silicon exposes unified CPU-GPU memory, but the cache state left after a completed GPU command is not documented. This paper characterizes that phase boundary on a 14-core Apple M4 Pro. We validate the measurement pipeline against unmodified STREAM 5.10 and BabelStream 5.0, then adapt an 8192-byte system-level-cache occupancy pattern to a synchronized Metal experiment. A GPU kernel touches 0 to 512 MiB and finishes before a 16 MiB CPU probe begins. The first CPU traversal is slower after large GPU footprints, while a second traversal removes most of the cost, showing residual shared-cache displacement rather than simultaneous DRAM contention. A separate matched-block experiment measures GPU slowdown under high-priority CPU traffic and finds background QoS close to baseline. Root PMU measurements and public IOReport histograms provide hardware grounding: they distinguish L1D refill sectors from software cache-line size, expose page-offset-dependent conflict behavior, and separate performance-core, efficiency-core, and AGX demand. The results identify a reproducible post-GPU cache-displacement window on M4 Pro and quantify a simple one-pass software recovery mechanism.
