## Does Quantum Computing Have a Speed Problem That Fidelity Metrics Miss?

Yes — and a new benchmark from Andrew Wack and [Riverlane](https://quantumintel.tech/companies/riverlane) is designed to expose it. The paper formalises **CLOPS_h** (Circuit Layer Operations Per Second, hardware-aware), targeting a sustained execution rate of over one million circuit layer operations per second as the defining standard for assessing real-world quantum processor speed. Until now, the field has leaned heavily on [gate fidelity](https://quantumintel.tech/glossary/gate-fidelity), [coherence time](https://quantumintel.tech/glossary/coherence-time), and quantum volume — metrics that characterise component quality under near-ideal conditions but say nothing about how fast a machine can grind through layered, parameterised circuits in the steady-state workloads that actually matter for variational algorithms, Trotterised dynamics, and error-mitigated experiments.

The core insight is blunt: a processor with excellent fidelity but poor sustained throughput may be practically useless for statistically meaningful results at utility scale. CLOPS_h directly addresses this by measuring the sustained rate at which a system executes physical layers — parallel slices of qubit-disjoint two-qubit gates separated by synchronisation barriers — under independently verified, steady-state operating conditions, inclusive of all execution pipeline costs.

---

## What Exactly Is CLOPS_h and How Does It Differ from the Original CLOPS?

[CLOPS](https://quantumintel.tech/glossary/clops) was introduced earlier as CLOPSv — a measure of how quickly systems execute parameterised circuits interacting with runtime environments, derived from Quantum Volume circuit families. That framing linked speed to an established quality metric, which was a useful starting point. But Quantum Volume circuits are not representative of the hardware-aware layered circuits used in today's near-term workloads spanning more than 100 qubits.

CLOPS_h reinstantiates the framework over **explicitly layered, hardware-aware circuits** compatible with layer fidelity benchmarking. Each layer represents one time slice of an N-qubit circuit, so the measured execution rate maps directly to the execution rate of layered N-qubit circuits — connecting cleanly to published device benchmarks. This is the critical technical upgrade: the benchmark is no longer tethered to the circuit topology of quality metrics that were designed for a different era of system scale.

The paper also draws an explicit distinction between **latency and throughput**. Short-duration benchmarks measuring small circuits are dominated by transient effects: compilation warm-up, control loading, pipeline priming. Most practical workloads — variational quantum eigensolvers, error-mitigated ground-state energy calculations, Trotterised time evolution — operate in steady state with pipelines continuously filled over extended periods. A benchmark that doesn't explicitly target steady-state behaviour will systematically mischaracterise long-running experiment performance.

---

## The Scale-Quality-Speed Triangle That the Field Is Now Acknowledging

The paper formalises what practitioners have known informally: quantum computing performance is governed by three interdependent attributes.

- **Scale** — how many qubits a system can programmably engage; the source notes that recent advances have enabled execution of circuits spanning over 100 qubits, but programmable qubits differ non-trivially from single physical qubits depending on architecture.
- **Quality** — [circuit depth](https://quantumintel.tech/glossary/circuit-depth) reliability, gate fidelity, and coherence, which dictate how far a computation can proceed before errors dominate.
- **Speed** — completed work per unit time, the dimension CLOPS_h is designed to capture.

Error mitigation is the forcing function that makes speed suddenly urgent. Techniques like probabilistic error cancellation and zero-noise extrapolation trade circuit repetition for improved accuracy, rapidly multiplying total computational cost. A system that needs ten thousand circuit executions to produce a statistically robust energy estimate at the desired accuracy is in serious trouble if its sustained throughput is low — even if every individual gate looks clean.

The analogy the paper reaches for is apt: classical HPC once reported peak floating-point rates that dramatically overestimated achievable system throughput, leading to the adoption of system-level benchmarks like LINPACK that measure sustained performance across the memory and interconnect hierarchy. CLOPS_h is the LINPACK moment for quantum processors.

---

## What Existing Benchmarks Get Wrong

The paper is notably critical of the current benchmarking ecosystem, and the critique is worth taking seriously.

**QED-C suite:** Represents the most systematic attempt at algorithmic-level benchmarking, measuring result fidelity and time across algorithm families. But it operates below utility scale, doesn't report execution overheads, and measures single-shot quality rather than sustained throughput. It falls short of characterising long-running experiment performance.

**Metriq:** Aggregates metrics into composite scores but excludes end-to-end overhead, covers circuits well below utility scale, and does not constitute a speed benchmark in terms of delivering correct output rapidly under realistic conditions.

**Maximum Circuits Per Second (MCPS):** A device-level metric that does set a hard ceiling on system throughput that software optimisation cannot exceed — a useful guard rail, but not sufficient on its own. CLOPS_h operates above MCPS in the benchmarking stack, capturing the full system-inclusive cost.

The conspicuous gap is application-level benchmarks. The paper cites Sample-based Krylov Quantum Diagonalisation (SKQD) applied to protein-ligand complexes exceeding 12,000 atoms as a domain-relevant workload that could anchor future application benchmarks — but acknowledges that tractable system-level benchmarking comes first. Application benchmarks require established scientific value, known classical references, and problem sizes beyond efficient classical simulation; otherwise they cannot distinguish quantum execution from a classical solver.

---

## Industry Implications

For hardware vendors, CLOPS_h introduces an uncomfortable accountability layer. A system can look excellent on qubit-level metrics — tight T1/T2, low two-qubit gate error rates from randomised benchmarking — while performing poorly on sustained throughput due to classical control bottlenecks, compilation overhead, or I/O latency in the classical-quantum interface. CLOPS_h will expose those bottlenecks publicly.

For enterprise buyers and [NISQ](https://quantumintel.tech/glossary/nisq)-era algorithm developers, the metric reframes the procurement question. The relevant question is no longer "what is this processor's two-qubit gate fidelity?" but "at what sustained rate can this system execute the layered circuits my variational or error-mitigated workflow requires, measured end-to-end in steady state?" Those are very different questions, and they may produce very different vendor rankings.

For the field moving toward fault-tolerant quantum computing, CLOPS_h is also a useful interim bridge. The logical-qubit error rates and QEC cycle times that dominate fault-tolerant analyses will eventually require their own system-level throughput characterisation — but establishing the discipline of speed benchmarking now, at the physical layer, builds the methodological infrastructure that will carry forward.

The involvement of Riverlane — a company whose core focus is quantum error correction infrastructure — is analytically significant. A QEC-focused organisation co-authoring a speed benchmark signals awareness that the path to fault tolerance runs directly through sustained throughput, not just error rates. Decoder latency, syndrome extraction speed, and classical processing bandwidth are all throughput problems in disguise.

---

## Key Takeaways

- **CLOPS_h** benchmarks the sustained rate of physical circuit layer execution, targeting over one million circuit layer operations per second, measured end-to-end in steady state with all pipeline costs included.
- The metric was developed by **Andrew Wack and Riverlane** and addresses a recognised gap: existing benchmarks characterise quality or peak performance but not sustained throughput under realistic workload conditions.
- **Error mitigation amplifies the urgency**: techniques that trade circuit repetition for accuracy multiply total computational cost, making sustained throughput a first-order constraint for practical experiments.
- CLOPS_h distinguishes **latency from throughput** — short-duration benchmarks dominated by transient effects mischaracterise steady-state performance, which is what long-running variational and error-mitigated experiments actually experience.
- The paper critiques QED-C, Metriq, and MCPS as insufficient for capturing system-level speed, drawing an analogy to how classical HPC moved from peak FLOPS to LINPACK-measured sustained performance.
- Application-level benchmarks — exemplified by SKQD on protein-ligand complexes exceeding **12,000 atoms** — remain largely undeveloped; CLOPS_h is positioned as a necessary stepping stone toward them.
- Hardware vendors whose strong qubit-level metrics mask classical control or I/O bottlenecks face increased exposure as CLOPS_h enters wider use.

---

## Frequently Asked Questions

**What is CLOPS_h and how does it differ from the original CLOPS benchmark?**
CLOPS_h (Circuit Layer Operations Per Second, hardware-aware) measures the sustained rate at which a quantum system executes physical circuit layers — parallel slices of qubit-disjoint two-qubit gates — under steady-state, end-to-end conditions. The original CLOPSv used Quantum Volume circuit families to link speed to quality metrics; CLOPS_h instead uses explicitly layered, hardware-aware circuits that match the topology of current utility-scale workloads and are compatible with layer fidelity benchmarking.

**Why does sustained throughput matter more than peak speed for quantum workloads?**
Variational algorithms, Trotterised dynamics, and error-mitigated simulations execute thousands to millions of parameterised circuit instances within classical-quantum feedback loops. Error mitigation techniques further multiply repetition counts. A system's performance on these workloads is determined by its steady-state throughput over extended periods, not by its latency on small, isolated circuits. Short-duration benchmarks dominated by transient effects like compilation warm-up systematically overestimate practical performance.

**What is the benchmark target performance cited in the paper?**
The paper cites a sustained execution rate of over one million circuit layer operations per second as the defining standard for meaningful quantum processor speed.

**Which existing benchmarks does the paper criticise, and why?**
The paper identifies QED-C as operating below utility scale without reporting execution overheads, measuring single-shot quality rather than sustained throughput. Metriq is cited for excluding end-to-end overhead and covering circuits well below utility scale. Maximum Circuits Per Second (MCPS) sets a useful device-level ceiling but doesn't capture full system costs. None constitute a speed benchmark in terms of delivering correct output rapidly under realistic, steady-state conditions.

**What is the analogy the paper draws to classical high-performance computing?**
Classical HPC once reported peak floating-point rates that dramatically overestimated real system throughput, prompting adoption of LINPACK, which measures sustained performance across memory and interconnect hierarchies. CLOPS_h applies the same principle to quantum systems: system-level, steady-state speed measurement inclusive of all execution costs, as opposed to isolated component or peak-rate figures.

**How does CLOPS_h relate to the path toward fault-tolerant quantum computing?**
While CLOPS_h operates at the physical layer in current NISQ and near-utility-scale systems, it establishes the methodological discipline of system-level throughput benchmarking. Fault-tolerant systems will require analogous characterisation of QEC cycle rates, decoder latency, and syndrome extraction throughput — all of which are sustained-throughput problems. Building that benchmarking culture now creates infrastructure that transfers directly to the fault-tolerant era.