CPU vs GPU vs QPU Explained: How Each Works and Why They Coexist

A CPU is built to finish one stream of instructions as fast as possible, a GPU is built to finish thousands of similar streams at once, and a QPU manipulates quantum amplitudes so that wrong answers cancel out. They coexist because each is good at a different shape of work, and the CPU still has to run everything else.

That one paragraph is the answer most people need. The rest of this guide is for readers who want to know why it is true: how each processor actually executes work, where its time and energy go, what the published numbers say, and which workloads belong on which chip. We use vendor documentation and peer reviewed papers for every figure, mark peak numbers as peak, and say plainly where a vendor has not published something. Every computed number below was checked in Python before it was written down.

Key takeaways

• Different goals, different silicon. NVIDIA's CUDA Programming Guide puts it simply: GPUs "devote more transistors to data processing units, while CPUs dedicate more transistors to data caching and flow control." A QPU is not a faster version of either. It is a different kind of machine.
• Latency versus throughput. A CPU core hides memory delay with caches, out of order execution and branch prediction. A GPU hides it by keeping many warps of 32 threads in flight and switching between them. A QPU has no delay to hide in that sense; it has a coherence clock that runs out.
• Data movement decides most comparisons. On Mark Horowitz's widely cited 45 nm figures, a 32 bit floating point multiply costs about 3.7 pJ while a DRAM access costs 1.3 to 2.6 nJ. Moving data is the expensive part, which is why a GPU on the other side of a PCIe link can lose to a CPU on simple jobs.
• Today's QPUs are small and noisy. Google's Willow chip has 105 qubits with a mean two qubit gate error of 0.33 percent in its error correction configuration. Quantinuum lists 56 qubits for its H2 system and IBM lists 156 qubits for Heron r2 and r3. None of them can factor an RSA key, and published resource estimates for breaking RSA 2048 still need close to a million noisy qubits.
• Hybrid is the normal case. A GPU cannot boot itself, and a QPU needs classical electronics, a classical decoder and a classical optimiser around it. The CPU is the host in both cases.
• The software around all three is a supply chain. Microcode, GPU drivers, CUDA toolkits, quantum SDKs and cryptographic libraries are components with versions and vulnerabilities. That is the only part of this story where Safeguard has a role, and we keep that role narrow below.

The three processors at a glance

Before going deep, here is the whole comparison in one table. Every row is explained later in the post.

How a CPU works: built for latency

A CPU core's job is to take one instruction stream, written as if each instruction runs after the one before it, and make it finish as quickly as possible. Almost every structure in a modern core exists to cut the time between "this instruction is next" and "this instruction is done."

The pipeline and the front end

A core splits each instruction into stages (fetch, decode, rename, schedule, execute, retire) and overlaps them, so many instructions are in different stages at the same moment. The front end has to keep the rest of the core fed. Intel's Optimization Reference Manual (order number 248966-048, August 2023) describes the Golden Cove core used in its 12th generation client parts and in Sapphire Rapids Xeon processors this way:

• legacy decode fetch bandwidth increased from 16 to 32 bytes per cycle;
• the number of decoders increased from four to six, "allowing decode of up to 6 instructions per cycle";
• the micro-op cache can deliver up to 8 micro-ops per cycle;
• the instruction decode queue holds 144 micro-ops per logical processor in single thread mode, or 72 per thread with SMT active;
• allocation width rose from 5 to 6 micro-ops per cycle and retirement width from 4 to 8, with execution ports increased from 10 to 12.

Those are the vendor's own figures. One number many readers want, the reorder buffer size, is not given as a count in that section: the manual only says there was "a significant increase in size of reorder buffer, load buffer, store buffer, and reservation stations." We do not repeat third party estimates here.

            Simplified out of order CPU core (one core, one thread)

  +-----------+   +-----------+   +---------------+   +-------------------+
  |  Branch   |-->|  Fetch    |-->| Decode (x6)   |-->| Rename / allocate |
  | predictor |   | 32 B/cyc  |   | uop cache (8) |   |  (6 uops / cycle) |
  +-----------+   +-----------+   +---------------+   +---------+---------+
                                                                |
                         +--------------------------------------+
                         v
               +-------------------+      12 execution ports
               | Scheduler /       |----> INT ALU, shifts, branches
               | reservation       |----> FMA / vector units (SIMD)
               | stations          |----> load and store address units
               +---------+---------+
                         |
                         v
               +-------------------+      results written back in any order,
               | Reorder buffer    |----> retired in program order (8 / cycle)
               +-------------------+
                         |
         L1 data cache 48 KB  ->  L2 1.25 MB (client) or 2 MB (server)  ->  shared L3  ->  DRAM

  Figures from Intel's Optimization Reference Manual, Golden Cove section. Layout simplified.

Out of order execution and speculation

The core does not wait for an instruction whose inputs are not ready. It renames registers so that false dependencies disappear, places ready micro-ops on whichever execution port is free, and keeps the original program order in the reorder buffer so that results become visible in the right sequence. When a load misses the cache, younger independent instructions keep executing behind it. This is the CPU's main tool for hiding latency: find other useful work from the same thread.

Branches are the obstacle. A conditional jump appears every handful of instructions in typical code, and the core cannot know which way it goes until the condition is computed. So it guesses, using a branch predictor that learns patterns, and executes down the predicted path speculatively. When the guess is wrong, the speculative work is thrown away and the pipeline refills from the right address. The cost of a misprediction scales with pipeline depth, which is why branch prediction structures get bigger every generation. Intel's manual for Golden Cove lists "improved branch prediction" and "bigger branch prediction structures" among the front end changes.

Speculation is also why CPUs are a security topic. Transient execution attacks of the Spectre and Meltdown family use the side effects of work that was later thrown away. The fixes are a mix of microcode updates, operating system changes and compiler changes. We come back to that when we discuss where the software supply chain meets the hardware.

Caches and the memory hierarchy

A DRAM access takes hundreds of core cycles. Caches keep recently used data close. The Golden Cove figure in Intel's manual shows a 48 KB L1 data cache and a 1.25 MB (client) or 2 MB (server) mid level cache per core, with a shared last level cache beyond that. Hardware prefetchers watch access patterns and fetch lines before the program asks for them. The design assumption is temporal and spatial locality: if you touched an address, you will probably touch it or its neighbours again soon.

That assumption is right for most general software and wrong for some important workloads, such as streaming through a 10 GB array once. Caches cannot help a single pass. Bandwidth can.

SIMD inside the CPU

A CPU core is not purely scalar. SIMD instructions (SSE, AVX, AVX-512 on x86; NEON and SVE on Arm; the V extension on RISC-V) apply one instruction to several data elements packed in a wide register. Intel's manual notes that some Skylake server processors have two AVX-512 FMA units, on ports 0 and 5, while others have one, and that code tuned for two FMA units may not be optimal on one. A 512 bit register holds 8 double precision or 16 single precision values, and an FMA counts as two floating point operations, so two 512 bit FMA units give a core 2 × 8 × 2 = 32 double precision FLOPs per cycle at peak.

SIMD is the CPU borrowing a GPU idea. It is narrower (8 or 16 lanes rather than 32 threads per warp and thousands of resident threads), it depends on the compiler or the programmer to vectorise, and it shares the core with all the latency machinery above.

What a CPU is good at

The CPU's strengths follow from its design:

• Irregular control flow. Parsers, interpreters, compilers, rule engines and business logic branch constantly and unpredictably. A CPU handles one branchy thread far better than a GPU, where divergent threads in a warp serialise.
• Pointer chasing and small random reads. Linked structures, B-trees and hash tables with poor locality depend on latency, not bandwidth.
• Operating system work. Interrupts, page tables, privilege levels, I/O and scheduling all live on the CPU.
• Short jobs. Anything that finishes in less time than it takes to hand work to an accelerator belongs on the CPU.
• Orchestration. The CPU decides what the GPU and the QPU do and when.

How a GPU works: built for throughput

A GPU starts from a different question: given a huge number of independent, similar pieces of work, how do we finish all of them per second, even if any single piece takes longer than it would on a CPU? Our companion guide on how GPUs work covers the graphics pipeline, shader cores and ray tracing; here we stay with general purpose compute.

Kernels, threads, blocks and warps

In CUDA, a program launches a kernel over a grid of thread blocks. NVIDIA's CUDA Programming Guide describes the hardware grouping: "Within a thread block, threads are organized into groups of 32 threads called warps. A warp executes the kernel code in a Single-Instruction Multiple-Threads (SIMT) paradigm." All threads in a warp run the same kernel code, but each can take different branches. When they do, the warp executes each path in turn with the inactive threads masked off, which is why divergent code wastes GPU throughput.

Blocks are assigned to streaming multiprocessors (SMs). Each SM holds many warps at once, along with a large register file and on chip shared memory. AMD's equivalent group is a wavefront, Intel's GPUs use a different vocabulary again, and the deeper posts in this series cover each vendor in turn.

              Simplified GPU (NVIDIA style naming)

  Host CPU --PCIe or NVLink--> +---------------------------------------------------+
                               |  GPU                                              |
                               |  +-----------+ +-----------+       +-----------+  |
                               |  |   SM 0    | |   SM 1    |  ...  |   SM n    |  |
                               |  | warp sched| | warp sched|       | warp sched|  |
                               |  | registers | | registers |       | registers |  |
                               |  | CUDA cores| | CUDA cores|       | CUDA cores|  |
                               |  | tensor    | | tensor    |       | tensor    |  |
                               |  | shared mem| | shared mem|       | shared mem|  |
                               |  +-----+-----+ +-----+-----+       +-----+-----+  |
                               |        +-------------+-------------------+        |
                               |                      v                            |
                               |              large shared L2 cache                |
                               |                      v                            |
                               |      HBM stacks (H100 SXM: 80 GB, 3.35 TB/s)      |
                               +---------------------------------------------------+

   Each SM keeps many warps resident. While one warp waits on memory,
   the scheduler issues an instruction from another warp that is ready.

Latency hiding by oversubscription

A GPU memory access is not faster than a CPU memory access. In many cases it is slower. The GPU's trick is that it does not need any single access to be fast. If an SM has enough resident warps, there is almost always one whose operands are ready, and the warp scheduler issues from that one while the others wait. Instead of a reorder buffer looking for independent instructions inside one thread, the GPU looks for independent threads.

This is why GPU programmers talk about occupancy: the number of warps resident on an SM relative to the maximum. Registers and shared memory are split among resident warps, so a kernel that uses many registers per thread lowers occupancy and gives the scheduler fewer warps to choose from. The series post on the streaming multiprocessor works through that arithmetic.

A timeline makes the difference concrete:

 One CPU core, one thread (out of order, but one stream of work)
 t ->  [compute][compute][load.....miss.......][compute][load..miss..][compute]
                           ^ OoO finds a few independent instructions, then stalls

 One GPU SM scheduler, four resident warps (simplified)
 t ->  W0:[c][ld.........wait.........][c][c]
       W1:   [c][c][ld.........wait.........][c]
       W2:         [c][c][c][ld.........wait.........]
       W3:               [c][c][c][c][ld.........wait...]
 issue: W0 W1 W1 W2 W2 W2 W3 W3 W3 W3 W0 W0 W1 ...   (an instruction issues almost every cycle)

Tensor cores and other matrix engines

Most of a modern data center GPU's peak arithmetic sits in matrix units rather than in the general CUDA cores. NVIDIA's H100 product page lists, for the SXM version, 34 TFLOPS of FP64, 67 TFLOPS of FP32 and 67 TFLOPS of FP64 on tensor cores. For lower precision tensor math it lists 989 TFLOPS of TF32, 1,979 TFLOPS of BF16 and FP16, and 3,958 TFLOPS of FP8, and every one of those tensor figures carries NVIDIA's own footnote "with sparsity." Dense math without structured sparsity runs at a lower rate. These are peak figures from a vendor product page, not sustained measurements. The same page lists 80 GB of memory at 3.35 TB/s, a configurable thermal design power of up to 700 W, NVLink at 900 GB/s and PCIe Gen5 at 128 GB/s.

AMD's CDNA parts have matrix cores, Intel's GPUs have XMX engines and Apple's chips have their own matrix hardware. The vendor specific posts in this series cover each one.

What a GPU is good at

• Dense linear algebra. Matrix multiply has high arithmetic intensity: each value loaded is reused many times. That is where tensor cores reach most of their peak.
• Data parallel work with regular access. Image processing, many simulations on grids, signal processing, rendering, and most of neural network training and inference.
• Large batch inference. Many requests processed together look like one big matrix problem.
• Anything where the same operation runs on millions of independent items and the data can stay on the GPU between steps.

And what it is bad at: branchy single threaded code, small jobs, work that needs frequent round trips to the host, and problems whose data does not fit in GPU memory and cannot be streamed efficiently.

How a QPU works: amplitudes and interference

A quantum processing unit is not a faster CPU or a wider GPU. It stores and transforms a quantum state, and the only thing you get out of it is a sample from a probability distribution. If you want the fuller picture of qubits and hardware, our explainer What is quantum computing? covers the basics. Here we focus on the execution model, because that is what decides which jobs belong on a QPU.

State: 2 to the power n amplitudes

A register of n classical bits holds one of 2 to the power n values at a time. A register of n qubits is described by 2 to the power n complex numbers called amplitudes, one for each basis state. The probability of measuring a given bit string is the squared magnitude of its amplitude. Gates are unitary operations that rotate this state: single qubit gates change amplitudes locally, and two qubit gates create entanglement, correlations that no assignment of independent values to each qubit can reproduce.

It is tempting to say a QPU "tries every answer at once." That framing leads people astray. You cannot read the amplitudes. Measurement collapses the state and returns one bit string. The useful part of a quantum algorithm is arranging gates so that amplitudes for wrong answers interfere destructively and amplitudes for right answers interfere constructively, so that the right answer is likely when you measure. Grover's 1996 paper describes exactly this: by "properly adjusting the phases of various operations, successful computations reinforce each other while others interfere randomly."

Gates, shots and the coherence clock

A QPU program is a circuit: an ordered list of gates on specific qubits, followed by measurement. Because measurement returns one sample, the circuit is run many times. Each run is a shot, and the result is a histogram.

The hard limit is noise. Physical qubits lose their quantum state over time (energy relaxation is characterised by T1, dephasing by T2), and every gate has an error rate. A circuit has to finish before errors swamp the signal. Here are published figures for three systems, each from the vendor or a peer reviewed paper, with the date of the source.

These numbers are not directly comparable across rows. Vendors use different benchmarks (randomised benchmarking averages, layered gate error, quantum volume), and trapped ion and superconducting systems trade speed for fidelity differently. They do tell a consistent story: two qubit errors in the range of roughly one in a thousand to a few in a thousand, and qubit counts in the low hundreds at most on the systems cited here.

Error correction is the bridge

Because physical qubits are noisy, the long term plan is to encode each logical qubit across many physical qubits and correct errors continuously. That only works if the physical error rate is below a threshold. Google's December 2024 Nature paper, "Quantum error correction below the surface code threshold," reports a logical error rate suppressed by a factor of Λ = 2.14 ± 0.02 each time the code distance increases by two, reaching a 101 qubit distance 7 code with 0.143 percent error per cycle, and a logical memory that outlived its best physical qubit by a factor of 2.4. The spec sheet lists 909,000 error correction cycles per second, a surface code cycle of 1.1 µs. Our post on quantum error correction walks through surface codes in detail.

That is real progress, and it is also one logical qubit's worth of memory, not a fault tolerant computer.

                 Simplified QPU stack (superconducting style)

  Classical host (CPU, sometimes GPU)
     | compile circuit -> pulse schedule, run decoder, run optimiser
     v
  Room temperature control electronics (waveform generators, digitisers)
     | coaxial lines through the cryostat
     v
  Dilution refrigerator stages, down to the millikelvin plate
     |
     v
  +------------------------------------------------------+
  |  QPU chip: qubits + couplers + readout resonators    |
  |  gate = shaped microwave or flux pulse               |
  |  measurement = readout pulse -> classical bit        |
  +------------------------------------------------------+
     |
     v
  bit strings -> histogram over many shots -> classical post processing

Three ways of dealing with time

The cleanest way to compare the three processors is to ask what each does about time.

• The CPU tries to make each operation's wait shorter. Caches move data closer. Prefetchers fetch it early. Branch prediction avoids waiting for conditions. Out of order execution finds something else to do inside the same thread.
• The GPU accepts long waits and fills them. It keeps enough independent threads resident that the arithmetic units rarely idle. Each thread is slower than a CPU thread. The machine as a whole finishes far more work per second when the work is parallel.
• The QPU cannot wait at all. There is no "stall" in the classical sense because the quantum state is decaying the whole time. The program has to fit inside a budget set by gate errors and coherence. Error correction changes this by refreshing the state every cycle, but the refresh itself needs a fast classical decoder: the Willow paper reports an average decoder latency of 63 µs at distance 5.

That third point matters for hybrid systems. A QPU's classical companions are not optional accessories. They are part of the computation.

Memory and data movement: where the time and energy go

Most of the practical differences between a CPU and a GPU come down to how data moves. For a QPU, the equivalent question is how much information you can load in and get out.

Energy per operation, where published

The most cited public breakdown is Mark Horowitz's ISSCC 2014 keynote paper, "Computing's Energy Problem (and what we can do about it)." Its Figure 1.1.9 gives rough energy costs for a 45 nm process at 0.9 V:

The same figure breaks down the energy of one instruction on a simple in order processor at about 70 pJ, of which instruction cache access is about 25 pJ and register file access about 6 pJ, while the add itself is a sliver. In the paper's words, "the programmable nature of a processor has high energy overhead, 70pJ/instruction, vs. a few pJ for an operation."

Modern processes are several generations past 45 nm, so the absolute numbers are out of date. The ratios are the lesson, and they still drive design:

• A 32 bit floating point multiply plus add is about 3.7 + 0.9 = 4.6 pJ. A DRAM access at 1.3 to 2.6 nJ costs roughly 283 to 565 times as much.
• An instruction's overhead of about 70 pJ is about 700 times a 32 bit integer add at 0.1 pJ.

Here is why that matters for the CPU versus GPU split. If one instruction drives 16 SIMD lanes, the 70 pJ of overhead is shared, about 4.4 pJ per lane. If one instruction drives a warp of 32 threads, it is about 2.2 pJ per thread. Using the same 45 nm illustration, wide SIMD and SIMT turn instruction overhead from the dominant cost into a modest one. This is a teaching calculation, not a measurement of any current chip, but it is the logic that every throughput processor follows.

What about current chips? Vendors publish peak throughput and thermal design power, not energy per operation. You can derive a ceiling: H100 SXM at its listed 67 TFLOPS of FP32 and up to 700 W works out to about 95.7 GFLOPS per watt, or about 10.4 pJ per FP32 operation if the whole board power were spent on peak FP32 math. Real workloads run below peak and boards rarely sit at exactly their power limit, so treat that as an order of magnitude, not a measured efficiency.

For QPUs, no vendor source we checked publishes an energy per gate figure that can be compared with classical numbers. Most of the power in a superconducting system goes to the dilution refrigerator and the room temperature control electronics, not to the gates themselves, and the comparison only makes sense per useful result, which today's devices rarely produce for practical problems. We leave that cell blank rather than guess.

Rooflines and the ridge point

The roofline model compares a kernel's arithmetic intensity (floating point operations per byte moved from main memory) with a machine's ratio of peak compute to peak bandwidth. Below the ridge point, the kernel is memory bound; above it, compute bound.

For H100 SXM, using NVIDIA's listed peaks:

• FP32: 67 TFLOPS ÷ 3.35 TB/s = 20 FLOPs per byte.
• FP64 (non tensor): 34 TFLOPS ÷ 3.35 TB/s ≈ 10.1 FLOPs per byte.

For a CPU, take the memory system of AMD's EPYC 9654 as listed on AMD's product page: 12 memory channels of DDR5 at up to 4800 MT/s, 460.8 GB/s per socket, 96 cores, 384 MB of L3, 2.4 GHz base clock and a 360 W default TDP. The bandwidth number checks out from first principles: 12 channels × 4800 million transfers per second × 8 bytes = 460.8 GB/s.

AMD's product page does not list peak FLOPs, so we will not invent one for that part. Instead, take a hypothetical 64 core socket at 2.0 GHz where each core has two 512 bit FMA units (the arrangement Intel's manual describes for some server cores), attached to the same 460.8 GB/s memory system:

• FP64 peak: 64 cores × 32 FLOPs per cycle × 2.0 GHz = 4.096 TFLOPS; ridge point 4.096 TFLOPS ÷ 460.8 GB/s ≈ 8.9 FLOPs per byte.
• FP32 peak: 64 × 64 × 2.0 GHz = 8.192 TFLOPS; ridge point ≈ 17.8 FLOPs per byte.

The ridge points are surprisingly similar. The GPU's advantage on memory bound work is not a different ratio; it is the absolute scale. The H100's listed bandwidth is about 7.3 times the EPYC socket's listed bandwidth (3.35 TB/s ÷ 460.8 GB/s). On a per core basis the CPU gets 460.8 GB/s ÷ 96 = 4.8 GB/s per core when all cores stream at once, which is why memory bound code stops scaling on CPUs long before it runs out of cores.

   Attainable FLOP/s (log)                                  (not to scale)
        ^
        |                         ______________________ H100 FP32 peak (67 TF)
        |                       /
        |                     /      ridge = 20 FLOP/B
        |                   /
        |                 /         ____________________ hypothetical CPU FP32 peak (8.2 TF)
        |               /         /
        |             /         /    ridge = 17.8 FLOP/B
        |           /         /
        |         /  GPU    /  CPU
        |       / 3.35 TB/s/  460.8 GB/s
        +----------------------------------------------------> FLOPs per byte (log)
                0.17 (SAXPY)                   1,365 (8192 GEMM)

Worked example 1: SAXPY, a memory bound job

SAXPY computes y = a·x + y over single precision arrays. Each element does one multiply and one add (2 FLOPs) and moves 12 bytes: read x (4), read y (4), write y (4). Arithmetic intensity is 2 ÷ 12 ≈ 0.17 FLOPs per byte, far below either ridge point. Both machines are bandwidth bound.

Take one billion elements, so 12 GB of traffic:

For the PCIe case we assume about 64 GB/s in each direction, half of the 128 GB/s that NVIDIA lists for the H100's PCIe Gen5 link, which counts both directions together.

The answer flips depending on where the data lives. If x and y are already resident on the GPU, the GPU wins by about 7 times. If they start on the host and the result is needed on the host, the GPU path takes about 191 ms against about 26 ms on the CPU, so the CPU wins by a wide margin. This is the single most common mistake in "should this run on the GPU?" decisions: counting the kernel and forgetting the copies. All of these are peak bandwidth calculations; real transfers and kernels reach a fraction of peak.

Worked example 2: matrix multiply, a compute bound job

Now multiply two 8192 × 8192 single precision matrices. The FLOP count is 2 × 8192^3 ≈ 1.10 × 10^12. The minimum data is three matrices of 8192 × 8192 × 4 bytes, about 805 MB. Arithmetic intensity is about 1,365 FLOPs per byte, far above either ridge point. Both machines are compute bound.

Even counting the copies, the GPU path is about 29 ms against about 134 ms on the hypothetical CPU, and it gets much faster if tensor cores are used with TF32, BF16 or FP16 inputs. That is the shape of work GPUs were built for: lots of reuse per byte. Again these are peak arithmetic estimates, not benchmark results, and well tuned libraries on either processor reach a fraction of peak.

Worked example 3: a branchy, latency bound job

Consider walking a large hash table or B-tree for a stream of lookups, or parsing a large JSON document. Each step depends on the previous one (follow a pointer, compare, branch). There is little arithmetic, the access pattern is unpredictable, and the next address is unknown until the current load returns.

There is no clean roofline number here because the limit is latency, not bandwidth or FLOPs. A CPU core with large caches, a good branch predictor and out of order execution is the right tool. A GPU can be fast at some of these tasks if you restructure them, for example by batching thousands of independent lookups so that each warp handles 32 of them, which turns a latency problem into a throughput problem. If you cannot batch, keep it on the CPU.

Worked example 4: why classical machines cannot simply simulate big QPUs

To simulate an n qubit state exactly on a classical machine, you store 2 to the power n complex amplitudes. In double precision each amplitude is 16 bytes.

Google's 2019 Nature paper used 53 qubits and noted the state space has "dimension 2^53 (about 10^16)." This table is why random circuit sampling became the first "beyond classical" demonstration. It is also why GPUs matter to quantum computing: up to the low 30s of qubits, a state vector simulator on GPUs is the standard way to develop and test quantum programs, and smarter methods (tensor networks, approximate simulation) reach much further for circuits with limited entanglement. The table does not mean that every 53 qubit circuit is hard to simulate. Many structured circuits are easy.

Worked example 5: a QPU's error budget

Use the Willow chip 1 figure of 0.33 percent mean two qubit gate error and ignore every other error source for a moment. If errors were independent, the probability that a circuit with g two qubit gates runs without a single two qubit error is (1 − 0.0033)^g:

This is a simplification (real errors are not perfectly independent, and many algorithms tolerate some errors), but it shows the scale. Useful algorithms such as Shor's need millions to billions of gates. That is impossible without error correction.

Now the logical side. The distance 7 Willow memory has 0.143 percent error per cycle. Over 1,000 cycles, about 1.1 ms at 1.1 µs per cycle, the chance of no logical error is (1 − 0.00143)^1000 ≈ 24 percent. Over 10,000 cycles it falls to about 6 × 10^-7. One logical qubit at distance 7 is a milestone; running long algorithms will need much lower logical error rates, which in turn need larger codes and more physical qubits per logical qubit.

Data in and data out of a QPU

A GPU is limited by how fast you can move bytes. A QPU is limited by something stranger. Loading a large classical data set into amplitudes takes many gates, and reading results out gives you one bit string per shot. You cannot read the full state, so a QPU cannot return a big vector of answers. This "input and output problem" is why most proposed quantum speedups concern problems with a small input, a small output and a huge internal search or simulation: factoring an integer, estimating a property of a molecule, or sampling from a hard distribution.

The same idea on each processor, in code

Code makes the execution models concrete. The samples below follow the vendors' own documentation. We did not run them for this post: the GPU code needs an NVIDIA GPU and the quantum code needs the vendor SDKs, neither of which was available on the machine this post was written on. Treat them as illustrations of the programming model, not as tested recipes.

CPU: one thread per core, SIMD inside each core

// saxpy_cpu.cpp: y = a*x + y on the CPU.
// Build (example): g++ -O3 -march=native -fopenmp saxpy_cpu.cpp
#include <cstddef>
#include <vector>

void saxpy(float a, const float* x, float* y, std::size_t n) {
    // Split the loop across cores, and ask the compiler to vectorise
    // each core's chunk with SIMD instructions (AVX2, AVX-512, NEON, SVE).
    #pragma omp parallel for simd
    for (std::size_t i = 0; i < n; ++i) {
        y[i] = a * x[i] + y[i];
    }
}

int main() {
    const std::size_t n = 1u << 26;          // 64 Mi elements
    std::vector<float> x(n, 1.0f), y(n, 2.0f);
    saxpy(3.0f, x.data(), y.data(), n);
    return y[0] == 5.0f ? 0 : 1;
}

The CPU version is ordinary C++. Each core gets a contiguous chunk, and inside the chunk each instruction handles 8 or 16 floats. The loop stops scaling once every core is waiting on DRAM, which for SAXPY happens quickly.

GPU: one thread per element, many warps per SM

// saxpy_gpu.cu: y = a*x + y on an NVIDIA GPU (CUDA C++).
// Build (example): nvcc -O3 saxpy_gpu.cu
#include <cstdio>
#include <cuda_runtime.h>

__global__ void saxpy(float a, const float* x, float* y, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;   // one element per thread
    if (i < n) y[i] = a * x[i] + y[i];               // inactive threads are masked
}

int main() {
    const int n = 1 << 26;
    size_t bytes = n * sizeof(float);
    float *x, *y;
    cudaMallocManaged(&x, bytes);                    // unified memory for brevity
    cudaMallocManaged(&y, bytes);
    for (int i = 0; i < n; ++i) { x[i] = 1.0f; y[i] = 2.0f; }

    int block = 256;                                 // 8 warps per block
    int grid  = (n + block - 1) / block;
    saxpy<<<grid, block>>>(3.0f, x, y, n);           // the CPU launches, the GPU runs
    cudaDeviceSynchronize();                         // the CPU waits for the GPU

    std::printf("y[0] = %f\n", y[0]);
    cudaFree(x); cudaFree(y);
    return 0;
}

Three things in this file show the hybrid model. The host loop that fills x and y runs on the CPU. The saxpy<<<grid, block>>> launch is a request from the CPU to the GPU's driver. And cudaDeviceSynchronize() is the CPU waiting for the GPU to finish. With unified memory the copies are hidden, not removed: pages still migrate across the link, which is exactly the cost in worked example 1.

QPU: a circuit, run as many shots

# bell_qiskit.py: prepare a Bell state and sample it (Qiskit primitives).
from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler   # local, exact simulator

qc = QuantumCircuit(2)
qc.h(0)        # put qubit 0 in an equal superposition
qc.cx(0, 1)    # entangle qubit 1 with qubit 0
qc.measure_all()

job = StatevectorSampler().run([qc], shots=1000)
counts = job.result()[0].data.meas.get_counts()
print(counts)  # expected: roughly half '00' and half '11', never '01' or '10' in an ideal run

The same circuit in NVIDIA's CUDA-Q, whose documentation describes a unified programming model "designed for a hybrid setting" in which CPUs, GPUs and QPUs work together:

# bell_cudaq.py: the same Bell state in CUDA-Q.
import cudaq

@cudaq.kernel
def bell():
    q = cudaq.qvector(2)
    h(q[0])
    x.ctrl(q[0], q[1])
    mz(q)

# Runs on a simulator by default; a GPU accelerated simulator or real QPU
# backend is chosen with cudaq.set_target(...).
print(cudaq.sample(bell, shots_count=1000))

Notice what the QPU program returns: a histogram of bit strings. On a real device you would also see a small fraction of '01' and '10' results, caused by gate and measurement errors. On a simulator the state vector lives in CPU or GPU memory, which is worked example 4 in miniature.

Hybrid systems: the CPU as host

In practice none of these processors works alone. The CPU is the host in every system described in this post.

A CPU hosting a GPU

A discrete GPU is a peripheral. The CPU runs the operating system and the driver, allocates GPU memory, copies data, launches kernels and waits on results. Everything in the CUDA example above that is not inside the __global__ function runs on the CPU. The link between them sets the price of every hand off. NVIDIA lists 900 GB/s of NVLink bandwidth for H100 SXM against 128 GB/s for PCIe Gen5, a ratio of about 7, which is why multi GPU training systems use NVLink between GPUs and why tightly coupled CPU and GPU packages exist at all. The series post on GPU memory and interconnects goes into HBM, NVLink, PCIe and CXL in detail.

Good hybrid design follows from the worked examples:

1. Keep data resident on the GPU across many kernels. Copy once, compute many times.
2. Overlap copies with compute using streams, so the link and the SMs work at the same time.
3. Batch small requests until they form a large enough job to amortise launch and transfer costs.
4. Leave branchy control logic, I/O and small jobs on the CPU.

A CPU hosting a QPU

A QPU is even more dependent on classical machines. Look at the layers in the stack diagram above: compilation from circuit to hardware native gates and pulse schedules, the control electronics that generate the pulses, the readout digitisers, the decoders that interpret error syndromes, and the optimisers that decide what circuit to run next. All of that is classical.

Three published details show how tight the coupling has become:

• Decoders are on the critical path. The Willow paper reports real time decoding with an average decoder latency of 63 µs at distance 5, sustained up to a million cycles. A fault tolerant computer must decode faster than errors accumulate.
• Resource estimates assume fast classical control. Gidney's 2025 estimate for factoring RSA 2048 assumes, among other things, "a control system reaction time of 10 microseconds."
• Cloud services schedule hybrid loops. IBM's Qiskit documentation describes three execution modes, job, session and batch. Session mode gives "a dedicated window for running a multi-job workload," during which "the user has exclusive access of the system," so that variational algorithms that alternate between quantum circuits and classical optimisation run predictably.

           A variational hybrid loop (for example VQE or QAOA)

   +-------------------------- classical host --------------------------+
   |                                                                    |
   |  params = initial_guess                                            |
   |  repeat until converged:                                           |
   |      circuit = build_ansatz(params)          (CPU)                 |
   |      counts  = run_on_qpu(circuit, shots)    -------------------+  |
   |      energy  = estimate(counts)              (CPU or GPU)       |  |
   |      params  = optimiser.step(energy)        (CPU)              |  |
   |                                                                 |  |
   +-----------------------------------------------------------------+--+
                                                                     |
                                       +-----------------------------v--+
                                       |  QPU: compile -> pulses ->      |
                                       |  run shots -> bit strings       |
                                       +---------------------------------+

The GPU often appears in the quantum stack too: as the simulator during development, as a decoder accelerator, and as the place where post processing of large shot sets happens. CUDA-Q's framing of "CPUs, GPUs, and QPUs working together" is a fair description of how the field actually builds systems, whichever toolkit you use.

What QPUs can and cannot do today

This is the part of the comparison where marketing and evidence diverge most. Here is what the peer reviewed record and vendor technical documents support, separated from roadmaps.

Demonstrated

The Willow Nature article carries an author correction dated 28 April 2026; the figures we quote above are from the abstract as published on the article page.

Not demonstrated, and not close

• Breaking RSA or elliptic curve cryptography. Shor's algorithm, posted to arXiv in August 1995, factors integers and computes discrete logarithms in polynomial time on a fault tolerant quantum computer. No such computer exists. Craig Gidney's May 2025 preprint, "How to factor 2048 bit RSA integers with less than a million noisy qubits," lowered the estimate from his 2019 work with Ekerå (eight hours with 20 million noisy qubits) to "less than a week" with "less than a million noisy qubits," assuming a 0.1 percent gate error rate, a 1 µs surface code cycle and a 10 µs control reaction time. Compared with Willow's 105 qubits, a million is about 9,500 times as many, at better error rates than today's averages, running continuously for days. Today's QPUs do not break RSA.
• Speeding up general computing. There is no evidence that a QPU will run a web server, a database, a compiler or a neural network training loop faster than classical hardware. The known speedups are for specific problem structures.
• Searching any database in an instant. Grover's algorithm gives a quadratic speedup for unstructured search, not an exponential one. Against a 128 bit symmetric key that means about 2^64 sequential iterations instead of about 2^128 trials. Even at a hypothetical one million Grover iterations per second, 2^64 iterations would take about 585,000 years, and Grover's algorithm does not parallelise well. Symmetric cryptography with adequate key sizes is not the urgent problem; public key cryptography is.

Why post-quantum migration still matters

If today's devices are nowhere near breaking RSA, why migrate now? Because encrypted traffic recorded today can be stored and decrypted later if a large enough machine is ever built, and because replacing cryptography across a real estate of software takes years. NIST published its first three finalised post-quantum standards on 13 August 2024: FIPS 203 (ML-KEM, a key encapsulation mechanism), FIPS 204 (ML-DSA, a signature scheme) and FIPS 205 (SLH-DSA, a hash based signature scheme). Our explainer on quantum computers and cryptography covers the migration path in detail.

A sober reading of the field

John Preskill's 2018 paper that named the "NISQ" era (noisy intermediate scale quantum) set expectations that still hold: devices with 50 to 100 qubits "may be able to perform tasks which surpass the capabilities of today's classical digital computers, but noise in quantum gates will limit the size of quantum circuits that can be executed reliably." Eight years later the qubit counts are a little higher, the error rates are lower, and the first error corrected memories work. The useful, fault tolerant machine is still a roadmap item, not a product.

Why all three coexist

If GPUs are so much faster on parallel work, why do servers still have big CPUs? And if QPUs might someday solve problems no classical machine can, why would they not replace both? Four reasons.

1. Amdahl's law. Any program has a serial part. If 5 percent of a job cannot be parallelised, no number of GPU cores will make it more than 20 times faster. The serial part runs on the processor with the best single thread latency, which is the CPU.

2. The host role. Someone has to run the operating system, the driver, the network stack, the scheduler and the storage. A GPU does not boot an operating system, and a QPU cannot run classical control flow at all. The CPU is the host by design.

3. Specialisation pays only for the right work. Horowitz's figures show why: specialised hardware cuts instruction overhead, but only for operations it was built for. A GPU spends its transistors on arithmetic and register files that sit idle on branchy code. A QPU's entire value depends on an algorithm whose interference pattern gives a speedup. Outside their niches, both lose to a general purpose core.

4. Economics and data gravity. Data lives in CPU memory and storage, next to the applications that produce it. Moving it to an accelerator costs time and energy. For many tasks the cheapest correct answer is to compute where the data already is.

The result is a layered system: CPUs for control and irregular work, GPUs and other throughput accelerators for dense parallel math, and, eventually, QPUs as a specialised co processor for a narrow class of problems, each attached to a classical host. Our posts on AI chip architecture and what an AI accelerator is show the same pattern across TPUs, NPUs and other accelerators.

All three kinds of processor are also products of the same manufacturing chain. If you want to follow that chain down to the silicon, read how a GPU is made, then our explainers on photolithography and EUV lithography machines, and our look at software bills of materials for fab machines and firmware.

Which processor for which workload

Common mistakes

• Comparing peak FLOPs without bandwidth. Most real kernels are memory bound. Compute the arithmetic intensity first, then compare against the ridge point.
• Forgetting the copies. In worked example 1 the GPU wins by about 7 times on resident data and loses by about 7 times when the data starts and ends on the host.
• Treating "with sparsity" peaks as dense peaks. NVIDIA marks its H100 tensor figures "with sparsity." Dense rates are lower. Always read the footnote.
• Mixing up peak and sustained. Product pages list peaks. Well tuned libraries reach a fraction. Only measured benchmarks on your workload tell you the sustained figure.
• Assuming a GPU thread is like a CPU thread. Warps execute together, and divergent branches serialise. Code written for a CPU often needs restructuring, not just porting.
• Calling a QPU a faster computer. It is a sampler of quantum states. Without an algorithm that uses interference to amplify the right answer, a QPU has no advantage.
• Treating qubit count as the headline. Error rates, connectivity and coherence matter as much as count. A 56 qubit system with low error rates can outperform a larger noisy one on many tasks.
• Reading roadmaps as results. Separate what a peer reviewed paper measured from what a vendor plans. This post's table of demonstrations shows the difference.
• Ignoring the software stack. Microcode, drivers, CUDA toolkits and quantum SDKs change behaviour and carry vulnerabilities. Version them like any other dependency.

FAQ

What is the main difference between a CPU and a GPU?

A CPU is designed to run one thread as fast as possible, using caches, branch prediction and out of order execution to cut latency. A GPU is designed to run thousands of threads at once and hide latency by switching between warps, trading single thread speed for total throughput. NVIDIA's guide summarises it as GPUs spending transistors on data processing and CPUs on caching and flow control.

Is a QPU faster than a GPU?

Not in general. A QPU only has an advantage on problems where a quantum algorithm gives a speedup, such as factoring with Shor's algorithm or certain simulations of quantum systems, and only once it is large and accurate enough. The systems we cite have between 56 and 156 qubits, with two qubit error figures of roughly 0.1 to 0.4 percent, and do not outperform GPUs on practical workloads.

Can a quantum computer break RSA encryption today?

No. Shor's algorithm needs a fault tolerant quantum computer. The most recent published estimate we cite, Gidney's May 2025 preprint, puts RSA 2048 at under a million noisy qubits running for under a week, under optimistic assumptions about error rates. The largest systems cited here have 105 to 156 physical qubits. Organisations should still plan migration to the NIST post-quantum standards published on 13 August 2024.

Why do computers still need CPUs if GPUs are so fast?

Because a GPU is hosted by a CPU and only speeds up the parallel part of a workload. The operating system, drivers, I/O, branchy business logic and the serial part of every program run on the CPU. Amdahl's law limits the total speedup to the share of work that is parallel.

What is arithmetic intensity and why does it matter?

Arithmetic intensity is the number of floating point operations a kernel performs per byte it moves from main memory. If it is below a machine's ridge point (peak FLOPs divided by peak bandwidth), the kernel is limited by memory bandwidth. SAXPY has about 0.17 FLOPs per byte and is memory bound everywhere; an 8192 square matrix multiply has about 1,365 and is compute bound.

How much energy does a computer use per operation?

Vendors rarely publish it. The best known public figures are from Horowitz's 2014 ISSCC paper for a 45 nm process: about 0.9 pJ for a 32 bit floating point add, 3.7 pJ for a 32 bit floating point multiply, 10 to 100 pJ for cache reads and 1.3 to 2.6 nJ for a DRAM access. The absolute numbers are dated, but the conclusion holds: moving data costs far more than computing on it.

What is a hybrid quantum classical system?

A setup where a classical computer prepares circuits, sends them to a QPU, reads back measurement results and decides what to run next. Variational algorithms work this way, and error corrected systems need classical decoders running in real time. Toolkits such as Qiskit and CUDA-Q are designed around this loop.

Can GPUs simulate quantum computers?

Yes, up to a point. An exact state vector simulation of n qubits needs 2 to the power n complex amplitudes, about 17.2 GB at 30 qubits in double precision, which fits on one large GPU. Each added qubit doubles the memory, so exact simulation of 50 qubits would need about 18 PB. Approximate methods go further for circuits with limited entanglement.

Will QPUs replace CPUs and GPUs?

There is no evidence for that. QPUs are expected to act as specialised co processors for specific problems, always hosted by classical machines. Even a fault tolerant QPU would depend on CPUs and GPUs for control, decoding and everything that is not a quantum algorithm.

What do TFLOPS figures on GPU spec sheets actually mean?

They are theoretical peaks at a given precision, often for tensor or matrix units, and sometimes with structured sparsity. They assume every unit is busy every cycle. Real applications reach less, and memory bound applications reach far less. Compare like with like: the same precision, dense or sparse, and the same kind of unit.

Where Safeguard fits

Safeguard does not design, build or program CPUs, GPUs or QPUs, and nothing in Safeguard makes any processor faster. Safeguard does not do quantum computing, and it does not scan firmware or microcode. The fit is narrower and sits in the software around these processors.

All three come with a software supply chain. CPUs receive microcode and firmware updates from their vendors, often to fix speculative execution issues; those arrive through vendor and operating system channels, and tracking them is a job for your platform team and your vendors' advisories. GPU workloads depend on driver versions, the CUDA toolkit, libraries such as cuDNN and NCCL, container base images and Python packages such as PyTorch. Quantum development depends on SDKs such as Qiskit and CUDA-Q, installed from public package registries like any other dependency. Post-quantum migration starts with knowing which cryptographic libraries and versions you ship.

Where those components live in your repositories and container images, Safeguard's SBOM generation (SPDX and CycloneDX) and software composition analysis can list them, match them against vulnerability databases, rank findings with reachability analysis and open remediation pull requests. An SBOM shows which cryptographic libraries and versions are present; it is a starting point for a cryptographic inventory, not a complete record of which algorithms each system negotiates. A GPU image that has not been rebuilt in a year carries every vulnerability fixed in the meantime, and that gap between a published fix and a running fix is what the next section is about.

More in this series

Other posts in our GPUs, CPUs, QPUs and lithography series:

• AMD GPU Architecture Explained: GCN, RDNA, CDNA, Infinity Fabric and HIP
• CUDA Programming Model Explained: Grids, Blocks, Warps and Memory
• GPU Memory and Interconnects: HBM, GDDR, NVLink, PCIe, CXL
• CUDA vs HIP vs SYCL vs OpenCL vs Metal vs Vulkan vs Triton Compared
• GPU Software Supply Chain: Drivers, CUDA, cuDNN, NCCL and Your SBOM
• How a QPU Works: Qubit Chips, Fridges, Control Pulses and Readout
• How CPUs Work: Pipelines, Out-of-Order, Caches, Branches, SIMD
• How EUV Lithography Machines Work: Tin Plasma, Mirrors and High-NA
• How GPUs Work: Graphics Pipeline, Shader Cores, Ray Tracing and Compute
• Inside an NVIDIA SM: Warp Schedulers, Registers, Tensor Cores
• Intel GPU Architecture: Xe Cores, XMX, Ponte Vecchio and oneAPI SYCL
• NVIDIA GPU Architecture History: From Tesla and Fermi to Blackwell
• NVIDIA vs AMD vs Intel vs Apple GPUs: Architectures Compared
• Optimizing a CUDA Matrix Multiply Step by Step, From Naive to Tensor Cores
• Photolithography Explained: Contact Printing to DUV Immersion and Overlay
• Tile-Based GPUs Explained: Apple, Mali, Adreno, PowerVR and TBDR

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the Python and container dependencies in a GPU training or quantum development repository, and /scan . gives you a starting inventory.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. Teams that keep GPU build hosts or research code on their own network can run scans where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask which of your projects contain a given library version, for example a specific OpenSSL release when you start a post-quantum inventory.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Intel 64 and IA-32 Architectures Optimization Reference Manual, Volume 1, order number 248966-048 (August 2023)
• NVIDIA CUDA Programming Guide: Introduction
• NVIDIA CUDA Programming Guide: Programming Model (warps and SIMT)
• NVIDIA H100 Tensor Core GPU product page and specifications
• AMD EPYC 9654 product specifications
• M. Horowitz, "Computing's Energy Problem (and what we can do about it)," ISSCC 2014, DOI 10.1109/ISSCC.2014.6757323
• Google Quantum AI, Willow spec sheet (9 December 2024)
• Google Quantum AI and collaborators, "Quantum error correction below the surface code threshold," Nature (2024)
• Arute et al., "Quantum supremacy using a programmable superconducting processor," Nature 574 (2019)
• Kim et al., "Evidence for the utility of quantum computing before fault tolerance," Nature 618 (2023)
• Moses et al., "A Race-Track Trapped-Ion Quantum Processor," Physical Review X 13, 041052 (2023)
• Quantinuum System Model H2 product page
• IBM Quantum hardware page (Heron and Nighthawk)
• IBM Quantum documentation: execution modes
• NVIDIA CUDA-Q documentation
• J. Preskill, "Quantum Computing in the NISQ era and beyond," Quantum 2, 79 (2018)
• P. W. Shor, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer" (arXiv quant-ph/9508027)
• L. K. Grover, "A fast quantum mechanical algorithm for database search" (arXiv quant-ph/9605043)
• C. Gidney, "How to factor 2048 bit RSA integers with less than a million noisy qubits" (arXiv 2505.15917, May 2025)
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (13 August 2024)
• NIST news: NIST releases first 3 finalized post-quantum encryption standards (13 August 2024)

Last reviewed: 25 October 2026. Processor specifications, qubit counts and error rates change with each hardware generation; check the linked vendor pages and papers before relying on a specific figure.