How does backend.run differ from Qiskit Runtime primitives?¶
The existing Qiskit backend interface (backend.run()
) was originally
designed to accept a list of circuits and return shot counts for every
job. As our users’ needs changed, we realized that we would need a new,
more flexible tool to address those needs, and Qiskit Runtime was born.
Using Qiskit alone¶
Qiskit was originally designed to drive circuit execution directly. Qiskit users submit circuits and receive results from the jobs that are run on a quantum system. Often, these jobs are part of a larger algorithm that includes an iterative (variational) approach to optimize circuit parameters. In this sequence, queuing up each job results in longer processing times.
Using Qiskit Runtime¶
Qiskit Runtime offers advantages in workload performance. Variational algorithms can run on classical compute resources that are colocated with the QPUs through the Estimator primitive. This allows users to run iterative algorithm circuits back to back. In addition, sessions can drive a sequence of jobs without having to re-queue each job, avoiding latencies of queue wait times after the session is actively running. As a result, Qiskit Runtime is much more efficient than its predecessors.
Function |
backend.run |
Qiskit Runtime Primitives |
---|---|---|
Primitive interface as abstraction for circuits and variational workload |
No |
Yes |
Sessions to improve performance for a sequence of jobs |
No |
Yes |
Abstracted interface that allows for automated error suppression and mitigation |
No |
Yes |
Increased performance for variational algorithms |
No |
Yes |
Working examples of code developed by Qiskit community |
Yes |
Yes |
OpenPulse |
Yes |
No |
Pulse Gates |
Yes |
Yes |
Dynamic circuits |
Yes |
No |