Quantum Emulator vs Simulator

Most vendors use the words emulator and simulator interchangeably, which is why the question keeps getting asked. Underneath the loose usage there is a real distinction, and it decides which one you should be running.

The short answer

A simulator computes what the mathematics says should happen. An emulator reproduces what a particular machine would actually do, noise included.

That is the whole difference. One answers the question "what does this algorithm output", the other answers "what would this device return if I sent it this circuit". Those are different questions, they have different answers on purpose, and confusing them is the most expensive mistake available in this field.

If you are debugging an algorithm, you want the ideal answer, because you need to know whether the algorithm is correct before you find out whether the hardware can run it. If you are estimating whether a real device will give you anything usable, the ideal answer is no help at all and you want the noise.

What a simulator actually computes

An exact simulator stores one complex amplitude per basis state. An n-qubit circuit therefore costs 16 x 2^n bytes, and that exponent is the whole story: ten qubits is 16 KiB, thirty is 16 GiB, forty is 16 TiB, fifty is 16 PiB. Each qubit doubles the bill, so the distance between comfortable and impossible is about four qubits.

Nothing is approximated below that ceiling. The result is exact to floating-point precision, and the only scatter you see is shot noise from sampling the distribution, which is real sampling noise rather than an artefact of the method.

Four different things all called "the simulator"

The word covers at least four engines that work in completely different ways, and the differences matter more than the label. Every row below was produced on one consumer laptop, an Intel i7-12700H with 32 GB of RAM, with the GPU switched off:

Circuit                  Qubits   Engine        Wall time   Accuracy
GHZ (Clifford)            5,000   clifford      0.56 s      exact
QAOA MaxCut, p=3            100   mps.quimb     5.9 s       converged (dev 0.0)
Layered ansatz               80   mps.quimb     4.3 s       converged (dev 0.0)
Exact statevector            26   exact.cpu     2.7 s       exact

Five thousand qubits in half a second looks like a mistake until you notice the circuit is Clifford, which the Gottesman-Knill theorem says is classically tractable at any width. That is not a breakthrough, it is a category. The stabilizer engine is exact there and refuses anything outside the category rather than guessing.

The tensor-network rows are the interesting ones, because those results are approximate. A 100-qubit QAOA instance does not fit in any exact representation, so the engine truncates, and the honest question becomes how far the answer sits from the truth. That is measured on the run rather than estimated, and it is published: a 40-qubit tensor-network job carries a discarded weight of 1.887e-14 and therefore an error bound of 1.943e-07, verifiable without an account at api.zksf.org/certify/11f4e32a020a43ca.

A stabilizer run says something different, because there is nothing to bound. A 1001-qubit error-correcting code circuit returns an exact result and says so on the certificate at api.zksf.org/certify/86125198363b4d02. No approximation, only shot noise.

Where the word emulator earns its place

None of the above models a device. They compute the mathematics, cleanly, as though the hardware were perfect. Emulation is what you get when you add the machine back in.

An emulator applies a noise model: depolarizing channels, readout error, gate infidelity, sometimes crosstalk and drift. The circuit is the same, the arithmetic is the same, and then the errors a particular processor is known to make are injected on top. The output looks like hardware output rather than like textbook output.

That is genuinely useful for asking whether an algorithm survives contact with a real device, and how much its output degrades at a given error rate. It is what a noise-modelling engine is for, and it costs a fraction of a hardware run.

It also has a limitation that is worth stating plainly, because it is the reason emulation does not replace hardware. A depolarizing model is an approximation of a device's actual error process. Real machines exhibit crosstalk, leakage, drift and correlated errors that no simple channel captures. An emulator tells you how your circuit behaves under the noise you modelled, which is not the same as how it behaves under the noise the device has.

And then there is the machine itself

Real hardware is neither a simulator nor an emulator. It is a physical apparatus whose measured behaviour is the result, and at every size a classical machine can reach, the classical machine gives the better answer, because it gives the noise-free one.

Two runs make the point concrete. On a Rigetti Cepheus superconducting processor, a 3-qubit GHZ at 50 shots returned 45 shots in the two ideal GHZ states and 5 in bit-flipped states, after roughly 53 minutes in the scheduled queue. On an IonQ Forte-1 trapped-ion processor, a 2-qubit Bell state at 100 shots returned 98 shots in the ideal outcomes and 2 in error, after about 5 hours queued. That second run carries a measured hardware fidelity of 0.9774 against the exact ideal distribution, at api.zksf.org/certify/df1d4c698a954051.

Neither run was faster or cheaper than the simulator, and neither was meant to be. What they provide is the measured behaviour of two qubit technologies, reported as raw counts with no error mitigation, post-selection or readout correction applied.

Which one do you want

Three questions settle it.

Is the question about the algorithm or about the device? About the algorithm means a simulator, and the ideal answer is the one you want. About the device means either an emulator, if you are exploring how noise affects the outcome, or the device itself, if the specific physical error process is the object of study.

Does the result need to be defensible? Exact and stabilizer results carry no approximation error by construction. Tensor-network and Pauli-propagation results are approximate and should arrive with a computed bound, or they are an assertion rather than a measurement.

Is the circuit within reach of an exact method? Under about 32 qubits, or Clifford at any width, or structured with bounded entanglement. If yes, approximation is unnecessary and the accuracy question does not arise.

The distinction that actually costs money

The reason this is not a vocabulary argument is that an approximate simulator does not fail loudly. Run one with insufficient bond dimension and it returns a normalised, plausible distribution and no warning. You get a confident wrong answer, and there is usually no way to tell it from a confident right one.

That is why every approximate result here carries a measured accuracy statement rather than a reassurance, and why exact and stabilizer results say so explicitly instead of leaving it implied. An emulator that models noise, a simulator that truncates, and a processor that is genuinely noisy all produce output that looks similar and means three different things.

Try it without any of this mattering

The fastest way to understand the distinction is to run something. There is a browser-based circuit simulator on this site that needs no account and no install: it runs exactly, in your tab, up to the point where exactness stops being possible, and then it tells you so.

Past that ceiling the same circuit runs on the hosted engines, on tensor-network and stabilizer methods past 1,000 qubits, and on real quantum processors from four vendors, through one API and without being rewritten. Every approximate result comes back with a bound you can cite, and every job can be exported as a certificate anyone can check. The same engines are available from the Android app if you want to run one from a phone.

If you would rather see what the difference looks like on a real industrial problem, the applications benchmarks run each one on our engines and on the best classical solver available, and publish both, including the runs where classical computing wins.