Skip to content

refactor(traits): device-portable PauliBackend abstraction (RFC scaffold) - #145

Closed
Roger-luo wants to merge 1 commit into
mainfrom
refactor/device-portable-pauli-map
Closed

refactor(traits): device-portable PauliBackend abstraction (RFC scaffold)#145
Roger-luo wants to merge 1 commit into
mainfrom
refactor/device-portable-pauli-map

Conversation

@Roger-luo

Copy link
Copy Markdown
Collaborator

What & why

Scaffold + design RFC for a de-biased map abstraction so a CUDA-backed map can be a drop-in Config::Map, giving CuPauliSum = PauliSum<CudaConfig>one Rust type, no parallel device type.

The current ACMap family is biased toward host (CPU) semantics in two ways that block a GPU backend:

  1. Host closures — every transform takes Fn(&W, &V) -> … (map_add_assign, map_insert*, scale, retain, contains_with). The gate math lives in these closures in ppvm-pauli-sum (sum/clifford.rs, rot1.rs, rot2.rs). You can't ship an arbitrary Rust closure to a CUDA kernel.
  2. Host-reference iterationACMapIter::Item = (&W, &V); a device-resident map can't hand out &V, and per-term host iteration would erase the GPU win.

PauliBackend instead reifies the (small, closed) Pauli-propagation vocabulary — Clifford 1q/2q, Pauli rotations, scale/merge/truncate/overlap — as data (gate + qubit indices + scalar coeffs). Each backend supplies a CPU loop or a GPU kernel.

What's in this PR (additive — nothing rewired yet)

  • docs/design/device-portable-pauli-backend.md — problem, design, CPU-vs-CUDA impl table, 7-step migration plan, open questions.
  • ppvm-traits: PauliBackend trait + Clifford1q/Clifford2q enums + PackedWord (canonical (u64,u64) encoding, shared with the CUDA backend).
  • reference::HashMapBackend — packed-key CPU reference proving the shape: Clifford-1q (10 gates) + scale_all/merge/truncate_abs/overlap/export implemented and tested (6 tests); rotations + 2q Cliffords marked ITERATE.

cargo test -p ppvm-traits and cargo check --workspace are green; main is untouched.

How to iterate

This is intentionally a scaffold so it can be picked up async. The migration steps and open questions (Complex coeffs on cuco's 8-byte path, where to hoist levi_civita/comm_2, truncation reification) are itemized in the design doc — grab a row.

🤖 Generated with Claude Code

Introduce a de-biased backend trait so a CUDA-backed map can be a drop-in
`Config::Map`, enabling `CuPauliSum = PauliSum<CudaConfig>` without a second
Rust type.

The current `ACMap` family is host-biased in two ways that block a GPU
backend: every transform takes a host Rust closure (`Fn(&W,&V)->...`), and
iteration yields host references (`(&W,&V)`). Neither can cross to a CUDA
kernel / device-resident map.

`PauliBackend` instead reifies the (small, closed) Pauli-propagation
vocabulary — Clifford 1q/2q, Pauli rotations, scale/merge/truncate/overlap —
as data (gate + qubit indices + scalar coeffs), so each backend supplies a
CPU loop or a GPU kernel.

This commit is additive (nothing rewired yet):
- docs/design/device-portable-pauli-backend.md: problem, design, CPU+CUDA
  impl table, migration plan, open questions.
- ppvm-traits: PauliBackend trait + Clifford1q/Clifford2q enums + PackedWord
  (the canonical packed encoding shared with the CUDA backend).
- reference::HashMapBackend: a packed-key CPU reference impl proving the
  shape, with the Clifford-1q family + scale/merge/truncate/overlap fully
  implemented and tested; branching ops marked ITERATE for follow-up.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jun 23, 2026

Copy link
Copy Markdown
PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-06-23 14:59 UTC

@Roger-luo

Copy link
Copy Markdown
Collaborator Author

hmm the problem is real here, but the abstraction is not the right shape, I prob need to redesign this myself instead of asking claude doing it... let me open an issue first

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.

1 participant