Repository navigation
OneSweep: refuse too few keys per thread; tile-size probe; performance notes - #96
Merged
Merged
Conversation
- 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
force-pushed
the
onesweep-probe
branch
from
November 10, 2026 00:29
3d1130a to
91e0110
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Trimmed to what should stay in OneSweep. The investigation's instruments are kept on the
onesweep-instrumentsbranch 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.mjsSweeps
KEYS_PER_THREAD, checks every sort against a CPU sort, and compares a pass with a copy kernel.docs/sort.mdbuffer_view, which cannot view atomics (confirmed in Dawn);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