Search arXiv⌕ Search

arXiv · 2610.21035

Caching Policies based on Object Sizes

Abstract

We evaluate eviction policies that consider the lengths of the objects being cached for different cache sizes (cost) and different workloads. Workloads include the Independent Reference Model and real-world production traces. In particular, hybrid policies are considered for segmented caches. A working-set approximation is developed for SIEVE as well as its length-aware extension.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Ridwanul Hasan Tanvir, George Kesidis. 2026-10-15. Caching Policies based on Object Sizes. https://arxiv.org/abs/2610.21035

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Top-Down Microarchitecture Analysis Without Causal Modelling Is Dangerous!

Top-Down Microarchitecture Analysis (TMA) is the standard for identifying CPU bottlenecks. However, TMA implicitly models performance via a single causal path: Workload(dataset, algorithm) => CPU(CPI) => System(Performance) (microarchitectural efficiency path). It overlooks two hidden causal paths: Workload(dataset, algorithm) => Instructions(Retired) => System(Performance) (algorithmic efficiency path) and Workload(dataset, algorithm) => Instructions(Retired) => CPU(CPI) => System(Performance) (microarchitecture-algorithm efficiency path). This causal blindness often misleads architects into futile hardware optimizations. To address this, we propose Causal Top-Down Microarchitecture Analysis (CTMA). Utilizing the object causal model, CTMA explicitly models these three causal paths among the workload, instructions, CPU, and system. We validate CTMA across Intel, AMD, and ARM platforms. Our experiments reveal counterintuitive insights: (1) CPI Profiling Blindness: Algorithmic instruction bloat can double elapsed time while the CPI profile remains frozen. (2) Over-Speculation Congestion: Throttling the Frontend paradoxically improves performance in pointer-chasing algorithms. (3) ILP Window Collapse: Extreme data topologies shift bottlenecks from Backend ROB capacity to Frontend fill-rate starvation. (4) Op-Cache SMT Overlap: Ultra-small footprints yield SMT speedups on Intel but cause severe thrashing on AMD. (5) "Ghost State" Artifact: Stale pipeline mitigations on Intel Xeon Gold 5120T artificially boost performance by 22.75% on SPEC CPU2017 and 42.2% on SPEC CPU2026. Based on this, we propose a dynamic speculation throttling mechanism.

cs.PF↗

How the Dirty Set Moves: Characterizing Schedule Reuse in Incremental Sparse Matrix Multiplication

Sparse matrices, in which most entries are zero, are central to scientific simulation, graph analytics and machine learning, and their multiplication with dense inputs is a core parallel kernel. In many applications the matrix stays fixed while only a few input rows change per step, so the result can be updated from those rows alone, which we call the dirty set. Sparse kernels often add a second optimization based on the inspector-executor principle, in which a tiled schedule is prepared once and reused across calls. However, when this reuse remains profitable as the dirty set moves is not well characterized. In this paper, we show that retained tiled execution rarely beats direct CSC in incremental sparse matrix multiplication, although incremental execution itself remains highly profitable. Across 21 SuiteSparse matrices and controlled patterns of motion, a direct column-wise incremental update is 2.1-8.2x faster than the best of eight full-recomputation codes, among them Intel oneMKL and PyTorch. Yet the same direct update outperforms a tiled executor that retains tile preparation and caches assembled schedules in 779 of 837 workloads. Separating reuse into per-tile preparation and cached schedules shows that the benefit comes from preparation; extra cache capacity seldom helps because a tile set rarely returns after a different one has intervened. Tiling is faster only when tiles merge many entries into each output write, a structural property that we predicted before measurement and confirmed on four held-out matrices of the same family. These results show that the structure of the matrix and the motion of the dirty set, rather than the sophistication of the schedule, determine whether reuse is profitable. We anticipate that our methodology and guidelines will help developers decide when to build schedule reuse into incremental sparse runtimes.

cs.PF↗

On the Robustness of Sparse Randomized Sketching to FP16 Rounding on GPUs

Randomized sketching replaces large matrices with smaller surrogates that preserve geometry for downstream numerical linear algebra. Sparse sketches promise faster formation than dense projections, but irregular GPU atomic updates become costly when each input row contributes to several output rows, as in SparseStack. FP16 accumulation halves sketch storage and update traffic, relieving cache pressure. How much does this rounding affect sketch geometry and downstream accuracy? For SparseStack with four nonzeros per column, cuSPARSE's FP16 path is slower than its FP32 baseline. Our custom kernel instead pairs FP32 inputs and signed products with packed FP16 vector atomic accumulation, turning lower precision into substantial gains. On NVIDIA H200, it forms complete sketches up to $1.91\times$ faster than our FP32 baseline and up to $1.58\times$ faster than cuSPARSE FP32. Under stated independence and range assumptions, random sketch signs cancel round-to-nearest conversion-error cross terms, giving expected squared Frobenius error no greater than ideal stochastic rounding. We assess accumulation empirically. At a sketch dimension of twice the number of input columns, the least-squares pipeline is $1.44$-$1.47\times$ faster than FP32, with median paired residual increases below $0.4\%$. Rescaling exposes range limitations and cases where stochastic conversion degrades accuracy.

cs.PF↗