Hold one engine against another without averaging reads into writes

[tamnd]

zu#78 asks for linkbench at ten times a rival at a concurrency of eight, and that number cannot be reached by any engine on any disk. LinkBench is thirty percent durable commits. A commit costs one flush of the drive, no engine goes below it, and two correct engines on one volume converge there however good either is. Even at a perfect write p50 of one sync the weighted ratio caps at 12.5x, and at the honest floor of two syncs it caps at 6.5x. A single blended number for that workload is measuring the drive and calling it the engine.

This adds gate --rival other.json, which splits the comparison into the two questions it was.

Reads are gated as a ratio against the rival, --read-speedup, default ten. That is where a ratio means something, because almost all of a read's latency is the engine's own work.

Writes are gated in units of one durable sync on the volume the run wrote to, which is the part of a commit the engine decides. At or under --commit-syncs, default two, at the median, and no more syncs a commit than the rival at either statistic. One sync is the floor since a durable commit has to flush. Two is what a writer pays arriving an instant after a flush began and waiting that one out before its own. A median above two is commits that are not grouping, which is the engine's to fix and not the drive's.

Two things the split has to get right to be worth trusting.

When both runs are on one machine both sides are divided by one number, the cheaper of the two probes. The probe is already a median of fifteen flushes and it still moves: this laptop came back at 3.02ms under one run and 4.35ms under another, a spread wider than the gap between passing the ceiling and failing it. Dividing each engine by its own probe would print two columns of one table in two different units and hand whichever engine drew the dearer probe a smaller count for free.

Where a flush never reaches a device the write half declines to rule. WSL2 on a virtual disk probes a durable sync at 316ns, which is a memory copy, and it would read a healthy 132us commit as four hundred syncs of work. A run there is reported indeterminate, not failed.

The comparison prints whether it passed or not, because a run that beat a rival by a hundred times said something worth reading.

Here is a real one, linkbench smoke at count 8000 and a concurrency of eight, one engine per invocation, on an M4 where a durable sync is a real F_FULLFSYNC:

rival: zu against ladybug on linkbench at a concurrency of 8
Class       zu p50   zu p99    ladybug p50  ladybug p99  p50 x   p99 x
----------  -------  --------  -----------  -----------  ------  ------
point-read  53.96µs  168.17µs  11.89ms      21.79ms      220.42  129.55
traversal   99.83µs  291.67µs  12.13ms      21.07ms      121.51  72.24
write       7.66ms   12ms      13.39ms      22.1ms       1.75    1.84

The read half clears ten times by two orders of magnitude. The write half is where the old blended number was going to die, and in syncs it reads as what it is rather than as a failure to be fast.

Nine tests cover the split, the two gates, the shared unit, the two hosts case, the unprobed volume, the volume that does not flush, and the printed form. go build ./... and go test ./... pass, gofmt -l is clean.