notes

Experiment 058

Bit-floor: fewer scan bits is NOT a QPS lever (negative)

Perf record: 058-bit-floor.json. Granite box (8 vCPU). vsearch --quant binary --rotate 2 --residual --scan-bits N. Cohere 1M × 1024. Task #3.

Hypothesis (from 049/050)

The scan cost is ∝ bits, and at scale we're bandwidth-bound — so halving the scan-bits should ~halve scan time → higher QPS, if residual+rotation hold recall.

Result — it doesn't pan out

scan-bitsrecall C=200QPS C=200recall C=500QPS C=500
10240.97810280.9952968
7680.9419180.982885
5120.84910160.930977
3840.75310510.8581014
2560.58811140.7161064

4× fewer scan words (1024→256) buys only ~+8% QPS (1028→1114) — while recall collapses (0.9952 → 0.716 at C=500).

Why the bandwidth-wall gain didn't materialize

At 1M with C=200–500, the scan is not the batch bottleneck — the rerank (C random f32 gathers × 1024-D) plus heap/selection dominate the per-query cost. So shrinking the scan 4× barely moves total QPS. And residual can't hold recall at 256-bit for 1M (far more competition than the 100k cell in 046, where 256-bit residual was ~0.86; here it's 0.72). So you pay a recall cliff for ~nothing.

Conclusion

The lever for QPS is not fewer bits. The scan is already cheap relative to the rerank at useful C, so the only ways to raise QPS are (a) make the per-doc op faster than popcount — SIMD ADC, Task #2 — or (b) cut the rerank cost — the PQ-prune tier, Task #1. Bit-flooring just trades recall for a rounding-error QPS gain. Dead end, consistent with 051.