Skip to content

OneSweep: refuse too few keys per thread; tile-size probe; performance notes - #96

Merged
jowens merged 3 commits into
mainfrom
onesweep-probe
Nov 10, 2026
Merged

jowens merged 3 commits into
mainfrom
onesweep-probe

Conversation

@jowens

@jowens jowens commented Nov 9, 2026 •

Copy link
Copy Markdown
Collaborator

Trimmed to what should stay in OneSweep. The investigation's instruments are kept on the onesweep-instruments branch and not merged.

Correctness: OneSweep refuses too few keys per thread

Each subgroup's digit histogram is staged in the tile. So a tile needs KEYS_PER_THREAD >= RADIX / subgroup width, which is 8 with 32-lane or emulated subgroups. With fewer, the sort was silently wrong; an M1 Max run with 4 keys per thread for u64 key-value looked fast because it was wrong. OneSweep now throws instead.

misc/onesweep_probe.mjs

Sweeps KEYS_PER_THREAD, checks every sort against a CPU sort, and compares a pass with a copy kernel.

docs/sort.md

  • How keys per thread works, and its limits.
  • Measurements on an M1 Max and a V100.
  • Where a 64-bit key-value pass spends its time on the V100: moving bytes 38%, work inside each tile 38%, scatter 20%, lookback ≤5%.
  • Improvements deliberately not made, kept on record:
    • non-atomic staging with WGSL buffer_view, which cannot view atomics (confirmed in Dawn);
    • staging key and payload together;
    • per-vendor tile sizes.

Left out (on onesweep-instruments): MAX_SPIN_COUNT, countFallbacks, ABLATE, and the fallback and ablation columns of the probe.

Depends on #101, which this branch contains; merge #101 first.

https://claude.ai/code/session_015kfNC6id65zEHzuAAH4jtJ


Generated by Claude Code

- The clear kernel (resetBuffersForBenchmarkingOnly, between trials)
  dispatched one invocation per word in one dimension, so a buffer of more
  than 16M words exceeded the 65535-workgroup limit: OneSweep's passHist
  for 64-bit keys, 8 keys per thread, at 2^24 (8 x 8192 x 256 words) on a
  V100. It now strides, with at most 65535 workgroups.
- OneSweep throws if KEYS_PER_THREAD's tile does not fit the device's
  workgroup memory, instead of failing pipeline validation later.
- slurm/job.sh reports the CPUs the job can use (nproc).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kfNC6id65zEHzuAAH4jtJ
…are subgroups

The emulated-subgroup CI job failed every 64-bit sort: with emulation
passWorkgroupBytes is an upper bound (about 1 KB high), so the new check
refused the 8 keys per thread that the default picks and that fit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kfNC6id65zEHzuAAH4jtJ
…e notes

- Each subgroup's digit histogram is staged in the tile, so a tile needs
  KEYS_PER_THREAD >= RADIX / subgroup width (8 with 32-lane or emulated
  subgroups); fewer sorted wrongly. OneSweep now refuses them.
- misc/onesweep_probe.mjs sweeps KEYS_PER_THREAD, checks every sort, and
  compares a pass with a copy kernel.
- docs/sort.md: keys per thread; measurements on an M1 Max and a V100; where
  a 64-bit pass's time goes (from the ablation builds kept on the
  onesweep-instruments branch); and improvements not made (non-atomic
  staging with WGSL buffer_view, which cannot view atomics; combined
  key+payload staging; per-vendor tile sizes).

The lookback and ablation instruments (MAX_SPIN_COUNT, countFallbacks,
ABLATE) are not merged: they live on onesweep-instruments.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kfNC6id65zEHzuAAH4jtJ
@jowens jowens changed the title OneSweep: lookback and tile-size instruments (MAX_SPIN_COUNT, countFallbacks, probe) OneSweep: refuse too few keys per thread; tile-size probe; performance notes Nov 10, 2026
@jowens
jowens merged commit bf09d80 into main Nov 10, 2026
4 checks passed
@jowens
jowens deleted the onesweep-probe branch November 10, 2026 01:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants