Ideal vs. noise-model simulators

Every simulator in the Select QPU dialog carries one of two labels: Ideal or Noise model. The label tells you what the simulator computes, and it also tells you how its run time responds when you raise the shot count.

Which backends are which

The two ideal simulators compute the same thing: the exact output of your circuit with perfect gates. Given the same circuit and enough shots, their counts converge to the same distribution. They differ only in speed and in which gates they accept.

Why ideal simulators ignore the shot count

An ideal simulator applies each gate of your circuit to a state vector once. When it reaches the final measurements, it has the exact probability of every outcome, and it draws as many shots from that distribution as you asked for.

Say your circuit has N gates and each gate takes time G to apply. Applying all the gates takes G·N. Drawing a shot is a lookup into a table of probabilities, so S shots add a small cost proportional to S. For any circuit worth simulating, that sampling cost is tiny next to G·N, and the total is close to O(G·N) whatever S is.

Drawing every shot from one pass over the state vector only works when every measurement comes at the end. A circuit that measures a qubit and then keeps applying gates to it, or that resets a qubit, can end in a different state depending on what each measurement returned. BasicSimulator handles such a circuit by running it again for every shot, so its time grows with S too. On a 10-qubit test circuit with one mid-circuit measurement, 1,000 shots took 13 seconds instead of 0.07.

Why noise-model run time usually grows with the shot count

A noise model describes how a real device goes wrong: after each gate there is some probability of an error, and each measurement can misread. A noise-model simulator samples those errors at random. One shot might get a bit flip after gate 40; the next might get none. Each shot is a different circuit, so the simulator has to apply every gate again for every shot.

Sampling the errors also adds work at every gate. Call that extra factor C. Each shot costs about C·G·N, and S shots cost O(C·G·N·S). Double the shots and the run takes roughly twice as long.

A simulator can avoid the per-shot loop by tracking the whole probability mixture of states as a density matrix. The simulator then samples all shots from that matrix, the same way an ideal simulator does. For n qubits a density matrix holds 4^n numbers against 2^n for a state vector, so each gate costs roughly 2^n times more.

Qiskit Aer, which runs the IBM simulators, can switch to the density-matrix method on its own once shots exceed 2^n, if every measurement comes at the end. Once it switches, the IBM simulators stop slowing down as you add shots. For a circuit on 10 active qubits the switch can happen above 1,024 shots. For 20 qubits it would take over a million, so in practice most circuits stay on the per-shot path.

Measured run times

These are timings for one 10-qubit circuit made of 20 layers of H, T and a CNOT chain. They were measured with native Python on one CPU core, with IBM Fez as the noise model. The browser runs the same libraries compiled to WebAssembly on one thread, so expect it to be several times slower, but the shape is the same.

The ideal simulators do not move. The IBM simulator has a fixed cost of about 10 seconds to set up a model of a 156-qubit device, then adds about 13 ms per shot. At 2,000 shots it has passed the 1,024-shot threshold, switched to a density matrix, and got faster. On a deeper circuit the per-shot cost dominates.

IonQ's remote simulators run on IonQ's servers, not in your browser, but the same rule applies: as Compute backends notes, IonQ runs one noise-model simulation per shot, so run time grows with the shot count.

Choosing an ideal or a noise-model simulator

• To check that your circuit is correct, use an ideal simulator. The built-in simulator is the fastest to start. Raise the shot count as far as you like.
• To see how noise changes your results, use a noise-model simulator, and start with a small shot count, such as 100. Raise it once you know how long one run takes.
• If a noise-model run is taking too long, lower the shot count or reduce the circuit depth before anything else. Transpiling with a higher optimization level often removes gates.

Related

• Compute backends
• Running your code
• Why your results look wrong
• Error mitigation