wai-quantum 0.6.8: threads only where they pay, and a cut-rank search that recounts only what moved #348

Merged

dcharlot merged 4 commits from wai/quantum-0.6.8 into main 2026-10-20 03:13:03 -04:00

Conversation 0 Commits 4 Files changed 17 +182 -44

dcharlot commented 2026-10-19 22:47:29 -04:00

Owner

Copy link

wai-quantum 0.6.8. Two speed changes. Neither moves a bit of any result: every kernel path gives the same bits at any thread count, and tests/bit_identity (23 pinned digests) passes.

State-vector threads only where they pay

A gate, a slice pass or a fixed-chunk sum now spawns at most one thread per 2¹⁸ amplitudes (threads_for).

• Each pass spawns its threads afresh, so below that size a thread costs more than its share of the work.
• On the shared 32-core build host, with the old rule (threads from 2¹⁴ amplitudes up), a gate ran 5 to 14 times slower than on one thread at 14 to 18 qubits (gate_timings, an ignored test that prints the times).
• A count a test forces is taken as it is, so threading_never_changes_a_bit still exercises the split paths at 16 qubits.
• The noisy suite (--lib quantum_noisy) now runs all 13 tests in about 20 s. One of them alone took 211 s before.

A cut-rank search that recounts only what moved

• ProductMeasured::anneal_order moves one qubit at a time. Seven moves in eight go at most four places, the rest anywhere.
  • Only the cuts between the two places are recounted, about a ninth of a full recount.
  • On the 70-qubit graph-state circuit, 300,000 moves reach a 29-bit widest cut in about 6 s.
  • In tests, every move's recounted cuts are asserted equal to a full recount.
• The service's cutrank method:
  • The planner makes one short search, enough to bound memory and work.
  • The run searches up to 300,000 moves from each of four seeds on threads of their own, with the planner's order among the candidates.
  • It keeps the cheapest order no wider than the planner's at its widest cut, so a job stays inside the memory it was admitted with.
  • On the live 70-qubit job, the planner's order had a widest cut of 31 bits.
• The READMEs describe the two-stage search, and the anneal command moves to 300,000 moves.

Checked on the build host

• check-lockfiles;
• --lib quantum_sv (8 passed), quantum_cutrank (7), quantum_noisy (13), --test bit_identity (23);
• the service's tests (64) and clippy.

The public-text checks are clean.

🤖 Generated with Claude Code

**wai-quantum 0.6.8.** Two speed changes. Neither moves a bit of any result: every kernel path gives the same bits at any thread count, and `tests/bit_identity` (23 pinned digests) passes. ### State-vector threads only where they pay A gate, a slice pass or a fixed-chunk sum now spawns at most one thread per `2¹⁸` amplitudes (`threads_for`). - Each pass spawns its threads afresh, so below that size a thread costs more than its share of the work. - On the shared 32-core build host, with the old rule (threads from `2¹⁴` amplitudes up), a gate ran 5 to 14 times slower than on one thread at 14 to 18 qubits (`gate_timings`, an ignored test that prints the times). - A count a test forces is taken as it is, so `threading_never_changes_a_bit` still exercises the split paths at 16 qubits. - The noisy suite (`--lib quantum_noisy`) now runs all 13 tests in about 20 s. One of them alone took 211 s before. ### A cut-rank search that recounts only what moved - **`ProductMeasured::anneal_order`** moves one qubit at a time. Seven moves in eight go at most four places, the rest anywhere. - Only the cuts between the two places are recounted, about a ninth of a full recount. - On the 70-qubit graph-state circuit, 300,000 moves reach a 29-bit widest cut in about 6 s. - In tests, every move's recounted cuts are asserted equal to a full recount. - **The service's `cutrank` method:** - The planner makes one short search, enough to bound memory and work. - The run searches up to 300,000 moves from each of four seeds on threads of their own, with the planner's order among the candidates. - It keeps the cheapest order no wider than the planner's at its widest cut, so a job stays inside the memory it was admitted with. - On the live 70-qubit job, the planner's order had a widest cut of 31 bits. - **The READMEs** describe the two-stage search, and the anneal command moves to 300,000 moves. ### Checked on the build host - `check-lockfiles`; - `--lib quantum_sv` (8 passed), `quantum_cutrank` (7), `quantum_noisy` (13), `--test bit_identity` (23); - the service's tests (64) and clippy. The public-text checks are clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 4 commits 2026-10-19 22:47:29 -04:00

wai-quantum: state-vector passes spawn threads only where each has 2^18 amplitudes; the cut-rank annealer recounts only the cuts a move changes ... 61e23bfe35

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

wai-quantum-service: cutrank's run searches longer, from four seeds, within the planner's widest cut; READMEs ... 645ac306b7

The planner's one search (about a second) bounds the job's memory and work.
The run searches up to 300 000 moves from each of four seeds on threads of
their own, with the planner's order among the candidates, and keeps the
cheapest order whose widest cut is no wider than the planner's. The wai-quantum
README's anneal command moves to 300 000 moves, which reach a 29-bit widest cut
on the 70-qubit circuit in a few seconds.

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

wai-quantum cutrank: clippy's is_multiple_of in the annealer ... 29148c06d3

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

wai-quantum 0.6.8: the changelog entry, and the version in every lockfile that pins it ... c7df1dd5a0

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

dcharlot merged commit 405b4d46fd into main 2026-10-20 03:13:03 -04:00

dcharlot referenced this pull request from a commit 2026-10-20 03:13:04 -04:00

Merge pull request 'wai-quantum 0.6.8: threads only where they pay, and a cut-rank search that recounts only what moved' (#348) from wai/quantum-0.6.8 into main

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!348

No description provided.