Benchmark: pivot the table around hardware, and stop measuring in memory

[marcobambini]

Two things, and the second one corrects a claim I put in the README a few PRs ago.

The table now compares hardware

It was organised by mode inside a per-machine section, which answers "which mode
should I pick" — a question whose answer does not vary by CPU. The comparison a
benchmark table exists for was buried.

Hardware	Vectors	Index	Max memory	ms/query	Mvec/s	Recall@20
Apple M5 Pro - NEON	1,000,000	INT8 preloaded	740 MB	37.6	26.6	99.5%
Apple M5 Pro - NEON	1,000,000	INT8 streamed	30 MB	115.5	8.7	99.5%

Two rows per machine, each self-contained; everything that does not vary by CPU
moved into the parameters above. make benchmark HARDWARE="..." prints exactly
those rows, in column order, so a contributor reformats nothing. Mode selection
keeps its own table, since which mode to choose is a property of the data and the
algorithms.

Max memory is measured, not the parameter echoed back — the benchmark brackets
vector_quantize_preload() with sqlite3_memory_used() and takes the high-water
mark across the query loop for the streamed case. Worth having as a measurement:
max_memory is a quantization parameter, and that it also bounds what the scan
holds was not obvious.

The database is now a file, never :memory:

An in-memory database puts the whole index in the process however the scan is
configured, which makes the memory column meaningless — the streamed row's entire
point is that the index is not resident.

FLOAT32 exact      148 -> 486 ms    reads 3 GB per query from the file
INT8 streamed       56 -> 116 ms    reads 740 MB through SQLite
INT8 preloaded    37.3 -> 37.6 ms   unchanged

That last line is the useful one: preloading makes the scan almost independent of
where the database lives, because after the one-time load it reads the extension's
own buffer and never returns to SQLite.

Correction

I previously wrote that TURBO4 is slower than the exact scan. That was an
artifact of measuring in memory. File-backed it is 3.2x faster, because the exact
scan pays to read 3 GB per query while TURBO4 reads 378 MB. TurboQuant does beat
brute force.

What survives is the comparison that mattered: INT8 is 4x faster than TURBO4 at
twice the index size, so TurboQuant's argument is memory rather than throughput.
Both the benchmark section and the older TurboQuant section now say that, and
#57 has a comment correcting
its numbers too — the FastScan case is unchanged, but the gap it has to close is 4x
against INT8, not the 20x+ the in-memory figures implied.

What the numbers still do not cover

Timings are best-of-20, so the file is in the OS page cache by then. That cache is
outside the process and evicted under pressure, so it is not in the memory column —
but it is why the streamed row is not paying for storage reads. On a device where
the index genuinely does not fit, add index size / storage bandwidth. The README
says so under the table.

No version bump: merging this will not cut a release, since make version still
reports 1.1.0.

🤖 Generated with Claude Code