{"id":"5f5199e1-1e5e-40cd-9daf-12dbbe26f7c4","arxiv_id":"2507.03092","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"STABSim is a GPU-accelerated Clifford tableau simulator with new measurement handling, exact T1/T2 noise sampling in a common regime, and a fast Clifford+T to PBC transpiler.","lead":"The authors built STABSim, a stabilizer circuit simulator that runs on GPUs and becomes faster than existing CPU simulators once surface-code circuits grow past about distance 11. It adds faster T1/T2 noise sampling, a chemistry Pauli-grouping example, and a Clifford+T to Pauli-based computing transpiler.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Unvalidated GPU measurement path: Algorithm 2's deterministic-measurement reduction has no oracle check and appears vulnerable to a scratch-row race; a wrong phase would invalidate every QEC/benchmark number.","rationale":"The reader's conditional verdict is well-founded, and I agree with the identified weakest assumption. The performance claims are implementation claims; pseudocode alone cannot establish that a CUDA kernel with grid.sync and atomic operations computes the same measurement semantics as sequential CHP. The deterministic-measurement path is the hardest part, and the paper's own text acknowledges the race-condition danger with the scratch row. Without a released artifact, the fastest way to settle the issue is differential testing against a trusted oracle. The T1/T2 noise model and transpiler are secondary contributions but also depend on measurement correctness; if the differential test passes, the main correctness risk drops substantially. I do not regard the performance claim as implausible; the detailed pseudocode and benchmark design are real work, but they do not rule out a mundane concurrency bug. My recommendation does not change the reader's conditional verdict, because the missing validation is exactly what the conditions should require.","tokens_in":24830,"tokens_out":8393,"duration_ms":108226,"concrete_test":"Release the STABSim artifact and run differential testing against a trusted CHP oracle, such as Stim's tableau simulator or an independent CPU rowsum implementation. Generate a corpus of circuits with deterministic and random X/Z measurements (random Clifford circuits of widths 20-200 and depths 50-1000, plus surface-code syndrome-extraction rounds), and after every measurement compare the full measurement outcome bit and, at the end, the complete 2n x (2n+1) tableau. Require exact equality with identical PRNG seeds; any single mismatch is a failure that would refute the correctness premise.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that STABSim is the first GPU tableau simulator to beat CPU methods in QEC rests on one load-bearing premise: Algorithm 2's GPU measurement reduction returns exactly the phase bit and tableau update that sequential CHP rowsum would return. The paper provides no independent evidence for this premise: no released code, no differential test against an oracle, and no machine-checked proof. Two red flags make the premise insecure. First, deterministic CHP measurement is a sequential recurrence: rowsum(temp, i) updates temp's x/z and phase before row i+1 is processed, and the g terms for later rows depend on the accumulated temp. Algorithm 2 instead appears to compute a parallel sum of per-row phase polynomials plus a single 2r[row]+2r[scratch] correction (lines 11-28), while lines 12-13 have every participating row read-modify-write the same scratch-row entry. Unless exactly one thread per (row, column) writes each entry and the ordering is defined, these writes race. Second, the pseudocode guards the entire reduction on an 'anticommutes' condition (lines 2-3). In a deterministic Z measurement, every stabilizer row has x=0 at the measured qubit, so the guard as written filters out exactly the rows that CHP's deterministic branch needs; if the guard is intended to mean something else, the paper never defines it. Since Figures 6-9 are all downstream of measurement correctness, a silent phase error would invalidate the QEC speedup, the T1/T2 noise model, and the transpiler numbers.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents STABSim, a stabilizer-tableau simulator with both a CPU implementation and a CUDA GPU implementation. The GPU design assigns one thread per stabilizer row for Clifford gates and uses warp-level primitives and block/grid reductions for measurement gates. The authors claim four contributions: (1) the first GPU tableau simulator to scale better than CPU simulators in QEC workloads, with a crossover at surface-code distance 11; (2) a T1/T2 noise model that is exact with constant overhead when T1 >= T2, obtained by compositing relaxation and dephasing into a single quasi-probability distribution; (3) a Pauli-grouping module for molecular Hamiltonians; and (4) a Clifford+T to Pauli-based-computing transpiler with T-count reductions matching PyZX at lower runtime. Section 3.1 describes the GPU kernel and Algorithm 2 gives the deterministic-measurement warp reduction; Section 4 reports benchmarks; the appendices provide pseudocode for the transpiler and for CHP rowsum.","tokens_in":25141,"tokens_out":10837,"duration_ms":122500,"significance":"If the algorithmic claims hold, the paper would address a real and important gap: QEC simulation is dominated by mid-circuit measurements, and earlier GPU Clifford simulators either did not beat CPU baselines or omitted measurements entirely. The row-parallel tableau layout and the use of warp primitives to reduce synchronization costs are a credible design direction. Contributions (2) through (4) are also potentially useful: an exact non-Pauli noise model with constant sampling overhead would improve on Pauli twirling, and a faster tableau-based PBC transpiler is practically relevant. The paper makes concrete quantitative predictions—the d>11 crossover, the exact T1/T2 sampling behavior, and the T-count reductions—that are checkable. However, the manuscript ships no code, data, commit hash, or machine-checked proofs, the central GPU measurement kernel is documented only by pseudocode that appears to contain a race condition and a contradictory guard, and the performance plots lack error bars and shot-count specifications. These issues are fixable in revision, but as submitted the central claims are not yet verifiable.","major_comments":[{"comment":"The deterministic-measurement reduction in Algorithm 2 must be reconciled with the CHP rowsum recurrence before any benchmark can be trusted. For a deterministic Z measurement every stabilizer row has X bit 0 at the measured qubit, so the guard `if anticommutes then` on lines 2–3 excludes exactly the rows that the deterministic branch needs; if the guard is intended to mean `if not anticommutes`, the pseudocode never says so. In addition, lines 12–13 perform a read-modify-write of the same `x_arr[scratch]` and `z_arr[scratch]` from every participating row, which is a race condition unless an ordering is defined; the text in Section 3.1.3 acknowledges that this single-index update is the race-prone part, but the pseudocode does not resolve it. Because Figures 6–8 are downstream of measurement correctness, the paper needs either a corrected race-free pseudocode with a proof that it reproduces sequential CHP rowsum, or a differential test against an independent tableau oracle on randomized circuits, and preferably both.","section":"§3.1.3, Algorithm 2"},{"comment":"The headline QEC speedup is not yet defined as a workload. Figure 6 reports wall-clock seconds for a surface-code circuit but does not state the number of shots, the noise model, or whether Stim was run in its default Pauli-frame sampling mode or in full-tableau mode. Stim's QEC advantage is substantially due to frame-based shot sampling, so a single-shot full-tableau time does not by itself establish that STABSim 'scales better than CPU methods in QEC workloads'. The revision should report the exact circuit generation procedure, number of rounds, error model, shot count, GPU and CPU clock/boost settings, and repeated-run statistics, and should compare against both Stim's sampler and Stim's tableau simulator. The platform description is also inconsistent: Figure 1's caption says the CPU is an AMD EPYC 7763, while Section 4 says CPU evaluations were performed on an AMD EPYC 7502.","section":"§4.1, Figure 6"},{"comment":"The exact-T1/T2 noise claim is asserted rather than demonstrated. The text states that the composite probability distribution is 'entirely positive' when T1 >= T2 and that the number of shots required scales as ∝ Γ^2, but no derivation of the composite quasi-probability is given, the conditions for positivity are not proved, and the figure is not compared against exact density-matrix simulation. Since the claim is that the method is exact with constant overhead, the authors should provide the explicit composite probability distribution or an equation-level derivation from the channel definitions, a proof of positivity for T1 >= T2, and a numerical comparison with a density-matrix solver for the same T1/T2 values.","section":"§4.2, Figure 8"},{"comment":"The T-optimization pseudocode is not self-contained. In the inner loop, `rowsum(T,S)` is invoked without defining the tableau `T`; the prose says a copy of the repeated stabilizer is appended to the next P tableau, while the pseudocode removes `S` from `P_{i+1}` and appends it to `P_{i+2}` inside the anti-commutation loop; and the convergence criterion only compares total row counts, which does not by itself certify that the extracted quarter rotations are correct. Please align the pseudocode with the prose, define all variables, and provide a correctness argument for the `rowsum+i` rule, ideally by checking the optimized circuits against an independent T-count and Clifford-equivalence tool.","section":"§3.3.3, Algorithm 5"},{"comment":"The paper provides no artifact, repository URL, commit hash, or raw benchmark data. For a performance-focused paper with several quantitative claims, this prevents independent verification of every figure in Section 4. The revision should include a reproducibility appendix with the source code, experiment scripts, benchmark data, and software versions for all baselines.","section":"Reproducibility"}],"minor_comments":[{"comment":"The abstract and Section 1 repeat 'first GPU-accelerated tableau stabilizer simulator' almost verbatim; after the first use, the later phrasing should be softened or cross-referenced.","section":"§1"},{"comment":"'large sale QEC' should be 'large-scale QEC'.","section":"§1"},{"comment":"The sentence 'To achieve these effects in stabilizer simulation,' is a fragment followed immediately by a new paragraph; it should be completed or removed.","section":"§2.7"},{"comment":"The function name `sim2d(cirucit, chunk_size)` contains a typo (`cirucit`), and the gate scheduler is described but not benchmarked, so its inclusion in the contribution list should be qualified.","section":"§3.1.4"},{"comment":"The caption and axis labels are difficult to parse: the left and right panels use different dimensionless ratios without clearly defining τ, and the text 'T2 2T1 Bound' is not explained. Please define every symbol in the caption.","section":"Figure 8 caption"},{"comment":"The table uses both 'GWC' and 'GC' for group-wise commutation; unify the terminology and state whether 'GWC' is the same as the 'GC' defined in Section 2.9.","section":"Table 2"},{"comment":"The column header 'Python Time' actually lists a speedup ratio relative to a Python reference, not a time; rename the column and state which reference implementation and version were used.","section":"Table 3"},{"comment":"The prose says 'Detailed tableau construction psuedocode is provided in Appendix 3'; this should read 'Appendix A.1' and the spelling 'psuedocode' should be corrected.","section":"§3.3.1"}],"recommendation":"major_revision","confidential_remarks":"The paper's strongest claim—a GPU tableau simulator that beats Stim on QEC workloads—is plausible but currently unverified. The issues are technical and addressable: the measurement kernel can be validated by differential testing against CHP rowsum, the benchmarks can be made reproducible with shot counts and error bars, and the noise claim can be supported by a derivation. The absence of code or data is a serious deficiency for a performance paper, and the Algorithm 2 pseudocode, taken literally, would not compute deterministic measurement outcomes. I am not recommending rejection because the scope of needed work is a revision plus artifact rather than a new research program. Please ask the authors to provide code and data before inviting a resubmission."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe paper is a solid systems contribution with a real chance of being useful: a GPU tableau simulator that handles measurements via warp reductions, a T1/T2 noise model claimed to be exact when T1 >= T2 via a positive composite quasi-probability distribution, and a Clifford+T to PBC transpiler that matches PyZX's T-counts much faster. The design discussion is careful, and the rowsum-based phase polynomial in Algorithm 1 is a nice way to avoid divergence. The PBC transpiler and the chemistry Pauli grouping are extra value, and the related work is handled honestly.\n\nThe soft spots are in the evidence chain, and they are not minor. The central claim—first GPU tableau simulator to beat CPU methods on QEC—rests entirely on the correctness of the measurement reduction. No code, no commit hash, no differential test against Stim or a sequential oracle. And Algorithm 2 as printed is worrying: in a deterministic Z measurement every stabilizer row has x=0 at the measured qubit, so the guard `x_arr[k*cols+a]` on line 2 would filter out exactly the rows the reduction needs. That looks like a transcription or logic error. The same pseudocode has multiple threads read-modify-write the same scratch row entry, which the text itself admits is a race condition. These could be artifacts of how the pseudocode was written, but with no artifact to inspect, the performance numbers in Figures 6-9 are not independently checkable. That is a load-bearing gap, not a cosmetic one.\n\nThe noise model claim is also stated rather than proven: the positivity of the composite distribution when T1 >= T2 is asserted with a figure and a pointer to Bennink et al., but no derivation appears in the paper. Anyone wanting to rely on it would have to redo the math. Benchmarks also lack error bars, and it's one H100 against one EPYC, so the crossover distance (d > 11) is a single data point.\n\nDespite these gaps, the paper deserves a serious referee. The ideas are new enough, the engineering is nontrivial, and the PBC transpiler speedups look real. I would send it to review with a request for the artifact, an oracle check on measurements, and a written proof of the positivity claim. If those land, this becomes a useful tool for QEC simulation at distance 11+.\n\nRead it if you work on stabilizer simulation or QEC benchmarking. I wouldn't cite the performance numbers until the artifact is out.","headline":"Plausible GPU speedups for QEC, but the measurement path is unvalidated and the pseudocode for the deterministic case looks off; needs code and a differential test before the headline claim can be trusted.","tokens_in":25673,"tokens_out":4160,"would_cite":false,"duration_ms":45291,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims the first GPU-accelerated tableau stabilizer simulator that scales better than CPU simulators on quantum error correction workloads, beating the best single-threaded CPU tools at surface-code distances above 11, and it…","keywords":["stabilizer simulation","GPU parallel computing","quantum error correction","surface code","CHP tableau","warp-level reduction","T1/T2 noise model","Pauli-based computing transpilation"],"falsifier":"Run a set of circuits with both deterministic and random measurements through the GPU simulator and through a sequential tableau reference, then compare the full tableau bits and measurement-outcome records bit for bit; any mismatch after a deterministic measurement would indicate a synchronization or reduction error. A cheaper check is to apply a known single-qubit error to a surface-code patch and verify that the syndrome read out matches the parity of the error pattern.","tokens_in":24641,"feed_emoji":"⚛️","tokens_out":6591,"duration_ms":69783,"temperature":0.7,"pith_summary":"The paper presents STABSim, a Clifford stabilizer simulator whose GPU implementation is claimed to be the first to outperform CPU-only simulators on quantum error correction workloads. The central claim is that measurement gates, historically the bottleneck that kept GPU stabilizer simulation slower than single-threaded CPU code, can be sped up enough with GPU warp-level reduction primitives and careful grid synchronization that the simulator scales better than the best CPU tools at surface-code distances above 11. A second claim is that composing the relaxation and dephasing channels into one quasi-probability distribution yields an exactly accurate T1/T2 noise model with constant sampling overhead whenever T1 >= T2, a regime covering most physical qubits. A third claim is that the same tableau machinery gives a Clifford+T to Pauli-based-computing transpiler that reaches the same T-count reductions as existing diagrammatic-reasoning optimizers while running orders of magnitude faster. The paper also gives a chemistry use case where Pauli grouping via fast bitwise commutation checks is used for Hamiltonian measurement.","feed_headline":"GPU tableau simulator outruns CPU rivals on big QEC codes","feed_subtitle":"Warp-level reductions crack measurement bottlenecks; exact T1/T2 noise sampling adds only constant overhead.","key_machinery":"The load-bearing object is the binary tableau of the CHP formalism: an array of X and Z bits plus phase bits that tracks both stabilizers and destabilizers, stored in flat global memory. The mechanism that carries the argument is a two-stage warp-level reduction for deterministic measurements: each thread computes a polynomial that expands the rowsum operation into one expression, intra-warp reductions combine 32 threads, shared memory and a second reduction combine a block, and a grid-wide atomic sum merges blocks into a global total that fixes the phase of a scratch row after a grid synchronization. Random measurements use a block-and-grid atomic-min search for an anti-commuting stabilizer, then the same threaded phase update. For noise, the key identity is the composition of the relaxation and dephasing channels into a single quasi-probability distribution, whose negativity (the sampling overhead) vanishes in the regime T1 >= T2.","core_discovery":"The central discovery claimed is that the measurement gate, the operation that previously kept GPU stabilizer simulators slower than sequential CPU code, can be parallelized successfully. The construction encodes the full tableau with destabilizers (the CHP formalism) in global memory with one thread per stabilizer row, trivializes Clifford gates as per-row bit flips, and handles measurement with a two-stage warp-level reduction that computes an outcome and simultaneously updates the tableau; deterministic measurements use a scratch row accumulated by all participating rows, with a global atomic reduction over blocks. Taken together, these choices produce a simulator whose per-qubit cost for QEC circuits is near-constant, crossing the CPU baseline at surface-code distance 11. The paper further claims that composing T1 relaxation and T2 dephasing into one quasi-probability distribution gives an exactly accurate channel with constant sampling overhead whenever T1 >= T2, and that the same tableau machinery lowers the runtime of Clifford+T to Pauli-based-computing transpilation by large factors while matching the T-count reductions of an existing diagrammatic-reasoning optimizer.","pith_inferences":["The gate-parallel mode of the simulator, which had little effect on QEC because measurements dominate, could give large speedups on Clifford-only workloads with few measurements, such as equivalence-checking tasks that previously relied on GPU gate simulation without measurement support.","The composite T1/T2 distribution suggests a general recipe: any non-Pauli noise channel whose combined quasi-probability distribution is non-negative could be sampled exactly with constant overhead, widening the class of physically realistic noise models accessible to stabilizer simulation.","A formal bit-for-bit cross-check between the GPU measurement reduction and a sequential tableau oracle would be a cheap and valuable addition, because without an independent oracle a race condition in the warp reduction would be nearly impossible to distinguish from a circuit or noise-model bug in the benchmarks."],"forward_implications":["Surface-code simulation with distance beyond 11 becomes faster on GPU than on the fastest CPU simulators, and the per-qubit cost stays almost constant as distance grows.","QEC workloads dominated by repeated syndrome measurements, normally the runtime bottleneck, no longer dominate the same way because measurements are parallelized across the tableau.","For physical qubits where T1 >= T2, the T1/T2 noise channel can be sampled exactly with a constant number of tableau samples per error location, avoiding the Pauli-twirling approximation error.","When T2 > T1, exact sampling still requires fewer tableau samples than prior quasi-probability methods.","Clifford+T circuits can be transpiled to Pauli-based computing with the same T-count reduction as existing optimizers but in a fraction of the runtime, easing the scheduling of T-gate factories in fault-tolerant architectures."],"supporting_citations":[{"why":"Supplies the rowsum algorithm and the destabilizer tableau structure that the parallel measurement reduction must reproduce exactly.","marker":"[2]"},{"why":"Defines the single-threaded CPU simulator whose per-qubit scaling forms the baseline the GPU implementation must beat.","marker":"[25]"},{"why":"Provides the commutation rules used to push Clifford operations through T rotations in the Pauli-based-computing transpiler.","marker":"[38]"},{"why":"Provides the quasi-probability decomposition of non-Pauli channels from which the composite T1/T2 noise model is derived.","marker":"[6]"},{"why":"Documents an earlier GPU tableau simulator that handled only Clifford gates, establishing the measurement bottleneck this work addresses.","marker":"[41]"},{"why":"Supplies the diagrammatic-reasoning optimizer used as the comparison target for T-count reduction speed in the transpilation evaluation.","marker":"[35]"}],"fun_headline_variants":["GPU stabilizer simulator breaks measurement bottleneck","First GPU tableau simulator surpasses CPU speed for QEC","STABSim: GPU Clifford simulator scales past CPU on QEC","Warp-level reductions make GPU stabilizer sims practical","Parallelized Clifford simulator: GPU outruns CPU for QEC"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The speedup claim rests on the assumption that the GPU's parallel measurement code, the two-stage warp reduction and the grid-wide scratch-row update, reproduces exactly the same phase bits and tableau rows as the sequential rowsum algorithm, since any race condition or misordered grid synchronization would silently corrupt measurements and invalidate the benchmarks.","fun_headline_variants_meta":{"raw":{"variants":["GPU stabilizer simulator breaks measurement bottleneck","First GPU tableau simulator surpasses CPU speed for QEC","STABSim: GPU Clifford simulator scales past CPU on QEC","Warp-level reductions make GPU stabilizer sims practical","Parallelized Clifford simulator: GPU outruns CPU for QEC"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000508,"raw_usage":{"total_tokens":2486,"prompt_tokens":969,"completion_tokens":1517,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":585,"completion_tokens_details":{"reasoning_tokens":1436}},"tokens_in":585,"tokens_out":1517,"duration_ms":11868,"temperature":1.0,"reasoning_tokens":1436,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T20:18:15.251036+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a set of circuits with both deterministic and random measurements through the GPU simulator and through a sequential tableau reference, then compare the full tableau bits and measurement-outcome records bit for bit; any mismatch after a deterministic measurement would indicate a synchronization or reduction error. A cheaper check is to apply a known single-qubit error to a surface-code patch and verify that the syndrome read out matches the parity of the error pattern.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the rowsum algorithm and the destabilizer tableau structure that the parallel measurement reduction must reproduce exactly."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents an earlier GPU tableau simulator that handled only Clifford gates, establishing the measurement bottleneck this work addresses."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the diagrammatic-reasoning optimizer used as the comparison target for T-count reduction speed in the transpilation evaluation."}],"review_version":1}