dash_read_bounds: time the short and long runs in turn, the least of seven each #400

Merged

dcharlot merged 2 commits from fix/dash-bounds-interleave into main 2026-10-21 14:38:59 -04:00

Conversation 0 Commits 2 Files changed 1 +19 -13

dcharlot commented 2026-10-21 12:56:12 -04:00

Owner

Copy link

tests/dash_read_bounds.rs failed on the linux-arm64 cargo-class corpora job of #396 and of #398. Neither PR touches DASH:

40000 attributes took 181.645665ms, 10000 took 10.836208ms   (#396)
40000 attributes took 120.173833ms, 10000 took 11.007458ms   (#398)

The reader is linear. Duplicate names go through a HashSet, and everything else reads slices. Two effects push a linear reader past the bound of 8 times on a busy virtual machine:

• CPU time includes host time. A thread's CPU clock also counts the time the host held the virtual CPU.
• Cache. The larger element's sets leave a cache the host shares, so each attribute costs up to about three times more.

That puts linear near 12 times, against 16 for a reader that scans the names read so far. The two are too close to bound.

Two changes:

1. Runs in turn. Each comparison times its two cases alternately, seven runs each, and keeps the least of each. A busy spell then slows both alike.
2. Sizes 32 apart. The attribute check now compares 1000 attributes with 32000. Linear is about 32 times, or about 100 with the cache effect. A quadratic reader is about 1000 times. The bound is 256 times plus 20 ms.

The run-by-run comparison check is unchanged apart from (1).

check (build host)	result
cargo test --no-default-features --features http --test dash_read_bounds, 10 runs	10/10 pass
the same with the reader made quadratic (each attribute scans the names read so far)	fails on the timing assertion every run: 32000 attributes took 3.61s, 1000 took 4.18ms (bound ≈ 1.09 s)

🤖 Generated with Claude Code

`tests/dash_read_bounds.rs` failed on the linux-arm64 cargo-class corpora job of #396 and of #398. Neither PR touches DASH: 40000 attributes took 181.645665ms, 10000 took 10.836208ms (#396) 40000 attributes took 120.173833ms, 10000 took 11.007458ms (#398) The reader is linear. Duplicate names go through a `HashSet`, and everything else reads slices. Two effects push a linear reader past the bound of 8 times on a busy virtual machine: - **CPU time includes host time.** A thread's CPU clock also counts the time the host held the virtual CPU. - **Cache.** The larger element's sets leave a cache the host shares, so each attribute costs up to about three times more. That puts linear near 12 times, against 16 for a reader that scans the names read so far. The two are too close to bound. Two changes: 1. **Runs in turn.** Each comparison times its two cases alternately, seven runs each, and keeps the least of each. A busy spell then slows both alike. 2. **Sizes 32 apart.** The attribute check now compares 1000 attributes with 32000. Linear is about 32 times, or about 100 with the cache effect. A quadratic reader is about 1000 times. The bound is 256 times plus 20 ms. The run-by-run comparison check is unchanged apart from (1). | check (build host) | result | |---|---| | `cargo test --no-default-features --features http --test dash_read_bounds`, 10 runs | 10/10 pass | | the same with the reader made quadratic (each attribute scans the names read so far) | fails on the timing assertion every run: `32000 attributes took 3.61s, 1000 took 4.18ms` (bound ≈ 1.09 s) | 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-21 12:56:12 -04:00

dash_read_bounds: time the short and long runs in turn, the least of seven each ... e3616f4e38

The linear-time check failed on a loaded linux-arm64 runner with both figures
about ten times their usual size (10000 attributes 10.8 ms, 40000 181 ms):
on a virtual machine a thread's CPU clock also counts the time the host held
the virtual CPU, so a busy host slows every run of one size before the other
is timed. Taking the two in turn lets a busy spell slow both alike, and seven
runs each make the least of each the run it disturbed least. The bounds are
unchanged: a reader that scans the names read so far still fails them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-21 14:25:09 -04:00

dash_read_bounds: 1000 attributes against 32000, bound at 256 times ... a4784fc68f

Interleaving was not enough: the linux-arm64 runner failed it again at
40000 against 10000 (120 ms, 11 ms). Linear reading of the larger element
costs up to about three times more per attribute when its sets leave a cache
a busy host shares, which puts linear near 12 times and a quadratic reader
at 16: too close to bound. With sizes 32 apart, linear is 32 times (about
100 with that cache effect) and quadratic about a thousand, and the bound
sits between them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit aa0b98d336 into main 2026-10-21 14:38:59 -04:00

dcharlot referenced this pull request from a commit 2026-10-21 14:39:00 -04:00

Merge pull request 'dash_read_bounds: time the short and long runs in turn, the least of seven each' (#400) from fix/dash-bounds-interleave into main

dcharlot referenced this pull request 2026-10-21 14:46:41 -04:00

wai.media.exploration: archives that replay, default-distance, a homogenization meter, and taste as a declared, owned objective (CO2, CO3) #406

dcharlot referenced this pull request 2026-10-21 15:05:27 -04:00

wai.media.upscale: super-resolution as an exact derivation, residuals against it, per-title priors, and an account of sink-made pictures (C3) #408

dcharlot referenced this pull request 2026-10-21 15:41:22 -04:00

wai.age.assurance: ratings carried through derivations, admission by an age threshold without identity, and the minors' profile (AGE) #409

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!400

No description provided.