Workload-Aware Autotuning of Block Size in Square-Root Decomposition

Abstract: The textbook choice B=sqrt(n) for square-root decomposition is asymptotically natural, but it is not always the fastest implementation choice. We study block-size autotuning as a reproducible algorithm-engineering problem and show that a learned workload model can improve over fixed sqrt(n) on the tested implementation. Under repeated grouped cross-validation, the best policy is a full-feature KNN-9 model that reduces mean regret from 1.2882 to 1.0646 and yields a paired geometric-mean speedup of 1.151x. A confidence gate retains most of that gain while reducing slowdowns. A family-free full-observation follow-up remains better than fixed blocking, which suggests that the model is learning from workload statistics rather than memorizing labels. In contrast, short-prefix variants do not produce a successful low-overhead online tuner in the current prototype. External validation is selective but supportive: Zipf-Hotspot is the strongest out-of-distribution case, and a six-window Baleen follow-up still improves over fixed blocking. Overall, block-size choice is workload aware and platform aware, and the fixed sqrt(n) rule leaves substantial performance on the table.

• The paper develops a workload-aware KNN-9 selector that lowers mean regret from 1.2882 to 1.0646 and delivers a 1.151x geometric-mean speedup over fixed √n blocking across 3,840 workloads.
• The method performs best for Hotspot and Short-Range workloads, where it adapts block size to locality and interval patterns, while a confidence gate preserves a 1.129x speedup by abstaining on uncertain predictions.
• The results show that tuning improves block-based implementations but does not universally outperform Fenwick trees, with transfer gains varying by compiler, CPU platform, and workload distribution, and short-prefix online tuning proving ineffective.

Motivation and scope

Square-root decomposition is conventionally taught with the block length $B=\sqrt{n}$, a rule that follows from minimizing $T(B)=\alpha\frac{n}{B}+\beta B$ when $\alpha$ and $\beta$ are treated as comparable constants. The paper argues that real implementations violate this simplification: boundary scans, full-block bookkeeping, cache locality, compiler choices, and the interval distribution of the operation stream all make the effective cost coefficients workload- and platform-dependent. The author therefore reframes block-size selection as a reproducible autotuning problem. The claim is deliberately narrow: not that blocking should replace Fenwick trees or segment trees generally, but that when a block decomposition is already deployed, a learned workload model can improve over fixed $\sqrt{n}$.

The contribution consists of a controlled benchmark over 3,840 workloads and 50,880 runtime samples; a compact learned policy; a confidence-gated deployment wrapper; explicit negative evidence for short-prefix online tuning; and transfer tests spanning seven compiler-flag configurations, two Windows platforms, and six windows of public Baleen storage traces.

Experimental design

The main suite varies $n\in\{4096,16384,65536,200000\}$, $m/n\in\{1,2\}$, query rates in $\{0.35,0.50,0.65\}$, eight workload families (Bimodal, Hotspot, Long-Range, Phased, Point-Heavy, Prefix-Suffix, Short-Range, Uniform), and twenty seeds. Each workload runs against the block implementation, a two-BIT Fenwick baseline, and a segment tree baseline, with checksum agreement required for acceptance. Timing uses two warm-up runs and seven measured runs, reporting the median.

The candidate set combines powers of two from 8 to 2048 with multiples of $\sqrt{n}$ for ratios $r\in\{0.10,0.25,0.50,1,2,4\}$, clipped to $T(B)=\alpha\frac{n}{B}+\beta B$0. Regret is defined as the ratio of achieved runtime to the finite-candidate oracle runtime. The learning target is $T(B)=\alpha\frac{n}{B}+\beta B$1 per (workload, block) pair, using features such as $T(B)=\alpha\frac{n}{B}+\beta B$2, interval-length statistics, point and full-range rates, family indicators, and block terms including $T(B)=\alpha\frac{n}{B}+\beta B$3 and $T(B)=\alpha\frac{n}{B}+\beta B$4. The model grid spans Ridge, inverse-distance-weighted KNN ($T(B)=\alpha\frac{n}{B}+\beta B$5), and random forests, evaluated under grouped cross-validation repeated over 20 seeds.

External validation applies the trained policy to 6,000 workloads from five unseen generators (including Zipf-Hotspot, a concentrated heavy-tailed profile) compiled under seven flag configurations — 42,000 matched pairs and 556,500 benchmark tasks. A focused low-concurrency replication on an Intel i9-14900HX and an AMD Ryzen 7 8745H tests whether high parallelism distorts conclusions.

Main results

The best configuration is full-feature KNN-9, which reduces mean regret from 1.2882 (fixed $T(B)=\alpha\frac{n}{B}+\beta B$6) to 1.0646, yielding a paired geometric-mean speedup of 1.151x. It wins on 1,289 workloads versus 387 losses, with a sign-test value of $T(B)=\alpha\frac{n}{B}+\beta B$7. Importantly, BIT remains faster overall at 1.957x relative to fixed blocking, so the result concerns the quality of the block-size default rather than a claim that blocking supersedes BIT.

Policy	Mean regret	Speed vs fixed
Fixed $T(B)=\alpha\frac{n}{B}+\beta B$8	1.2882	1.000x
Tuned (KNN-9)	1.0646	1.151x
BIT baseline	—	1.957x
Segment tree	—	0.408x

The gain concentrates in two families: Hotspot improves from regret 2.0845 to 1.0783 (geometric speedup 1.874x) and Short-Range from 1.8885 to 1.0844 (1.675x). Oracle analysis explains the mechanism: fixed $T(B)=\alpha\frac{n}{B}+\beta B$9 is too small for Short-Range intervals (excessive full-block bookkeeping) and too large for Hotspot intervals (excessive boundary scanning around localized clusters). The optimum is often sharp — only 1.48 candidates fall within 5% of oracle on average — which makes accurate selection consequential. The learned policy is thus a regime detector rather than a universal accelerator.

Model selection is stable: KNN-9 has mean rank 1.35 and is best in 14 of 20 CV seeds. Feature ablation shows distribution statistics matter most for transfer, since they remain measurable even when generator labels are unseen. A toy analysis explains why KNN fits: projected onto normalized interval scale and locality concentration, the preferred block size bends across regimes in opposite directions, so no single global linear model captures it.

A prediction-margin gate ($\alpha$0, abstaining when the gap between the two smallest predicted log runtimes falls below threshold) applies tuning on 89.3% of workloads, cuts slowdowns from 387 to 325, and retains a 1.129x speedup — a conservative deployment wrapper rather than a better policy.

Two follow-ups delimit the claim. A family-free variant (family one-hots zeroed) still achieves regret 1.0733 and 1.143x speedup, indicating the model learns from measurable statistics rather than memorizing labels. In contrast, short-prefix variants observing only the first 10%, 5%, or 1% of each workload fail as online tuners once feature-extraction and model overhead are counted — an explicit negative result.

External transfer

Transfer is selective. On Zipf-Hotspot, the strongest out-of-distribution case, the transferred policy exceeds BIT under all seven compiler configurations, with a 1.161x geometric-mean speedup over BIT across 8,400 pairs (the finite-candidate oracle reaches 1.344x). However, under native -O3, -Ofast, and LTO flags the transferred policy beats BIT but is slower than fixed $\alpha$1 (e.g., 0.934x under -O3 -march=native), evidencing compiler-sensitive distribution shift. The margin gate mitigates this: on the three native configurations it improves the ratio from 0.935x to 0.964x while remaining 1.116x faster than BIT, though it sacrifices some aggressive gains elsewhere.

The low-concurrency replications complicate the stronger structural claim. On the Intel machine at jobs=1, the Zipf-Hotspot crossover against BIT drops from 1.033x to 0.934x while the gain over fixed blocking persists (1.047x); on the AMD Ryzen 7 8745H, the crossover strengthens dramatically to 1.999x versus BIT. The stable conclusion is improvement over fixed blocking under concentrated locality; the crossover against BIT is platform dependent.

On six Baleen trace windows mapped into the range abstraction (GETs as queries, PUTs as updates, page ranges at 4 KiB granularity), the transferred policy reduces mean regret from 1.1754 to 1.0661 with a 1.104x speedup, winning five of six windows. Notably, the policy moves away from the textbook candidate near 1300–1600 pages toward much smaller blocks (32–256). The mapping is explicitly a workload-shape proxy, not a replay of storage semantics.

Limitations

The claims are platform-scoped: most measurements use one CPU and compiler family, with only a partial second-platform replication. The external suite remains synthetic despite its breadth, and the Baleen mapping introduces proxy distortion. Parallel benchmarking (24–32 jobs) leaves residual contention and scheduling effects that median-of-seven timing does not fully eliminate, as the Intel jobs=1 result demonstrates. The oracle is a finite-set upper bound, not deployable. Deployment questions — tuning cost, calibration latency, cross-platform portability — are deferred, and the short-prefix online tuner remains unsolved in the current prototype.

Conclusion

This paper establishes that block size in square-root decomposition is a workload-aware and platform-aware parameter, and that the fixed $\alpha$2 rule measurably underperforms a learned KNN-based selector on the studied implementation, with a reproducible 1.151x gain, a confidence gate preserving most of it, selective out-of-distribution validation on Zipf-Hotspot and Baleen traces, and honest negative results for online tuning. The open question the work leaves is how to reduce online observation cost and incorporate platform identity so that the offline gains survive low-latency deployment.