Fermi-Hubbard on a quantum computer, part 5: quantum advantage or time-to-answer?

Posted on by

"Quantum advantage" is a dangerous phrase. It sounds absolute: the quantum computer wins and the classical computer loses. For near-term many-body simulation, that is usually too crude.

The better question is more practical

How long does it take to obtain a useful observable for this specific task?

I will call that time-to-answer.

The task

The concrete task is not "compute the full quantum state exactly." For 120 qubits that would be absurd. The task is narrower:

  • take a 1D Fermi-Hubbard chain with 60 sites;
  • evolve to t = 6 with 30 Trotter steps;
  • measure local observables such as charge, spin, and double occupancy;
  • compare with classical references where possible.

The quantum computer does not have to give everything. It has to give a physically useful observable.

The simple speedup

If we compare the local chi256 MPS wall time with the Fire Opal main+readout execution proxy, we get:

\[\mathrm{speedup}=\frac{T_{\mathrm{classical}}}{T_{\mathrm{quantum}}}\qquad \frac{9033\,\mathrm{s}}{33.148928\,\mathrm{s}}\approx 272.5\]

That is an impressive number. But it is not the whole story.

Why not?

Because execution time is not the same as benchmark time. A fair comparison may count different things:

  • only quantum circuit execution time;
  • cloud wall time including service overhead;
  • queue time;
  • classical preprocessing;
  • layout and calibration search;
  • error mitigation;
  • post-processing;
  • classical convergence studies.

The chosen timing definition changes the claim.

If we compare only execution time, the quantum route looks strong. If we compare full workflow time, the situation becomes harder. But the same is true on the classical side. A classical method also has tuning choices: bond dimension, cutoff, truncation threshold, time step, symmetry sector, and convergence checks.

The hidden parameter

The Majorana-propagation comparison makes this point sharply. Cutoff 2 was very fast, even faster than the quantum execution proxy, but not accurate enough for mean double occupancy. Cutoff 4 was much more accurate, but took about 19 minutes.

The issue is not only the runtime of cutoff 4. The issue is that we do not know in advance that cutoff 4 is sufficient. To know that, we need comparison with a more expensive reference or a cutoff-convergence study.

That is exactly the time-to-answer question

Do we count only the runtime of the best classical parameter after it is known? Or do we also count the search needed to know that the parameter is reliable?

A fair statement

I would phrase the claim as follows

The quantum processor does not prove that no classical method can handle this task. But for this instance and this observable, the quantum route may have a better practical time-to-answer than a classical approximation whose accuracy depends on a truncation parameter that is not known in advance.

That is less dramatic than "quantum advantage." It is also better.

Why this matters

Near-term quantum hardware will probably not win by doing perfect universal simulation. The interesting cases are concrete tasks:

  • a specific Hamiltonian;
  • a specific observable;
  • a specific accuracy target;
  • a specific workflow;
  • a clear classical competitor.

In such a benchmark, it is not enough to say that a classical method exists which works after the fact. We also have to ask how much work was needed to know that it works.

The classical frontier moves

There is already a classical response to the Q-CTRL claim. Better symmetry-aware GPU tensor-network simulations can substantially reduce the original speedup. That is exactly how science should work. A quantum claim sets a benchmark, and classical methods improve.

So the claim should not be

classical is impossible.

The claim should be

for this task, the quantum route is a serious time-to-answer candidate, and the classical route should be counted including tuning and validation.

That is the real benchmark problem.

Sources and project links