I am currently doing some experiments using Variational Quantum Eigensolver in molecular dynamics using qiskit, and noticed that the time for execution on real backend is significantly higher than the simulated backend.

I am aware that this is normal, due to the overhead of quantum execution (i.e., resetting the qubits, transforming the circuit into waveforms and so on), and that for the type of instances I am using I cannot expect a speedup.

However, I would like to know if there are some "best practices" to take into account when executing my code on real backends. More precisely, I would like to know: is there a way that allows me to speed up the code, by knowing some architectural details (i.e., the topology and the type of qubits) or ways to prepare my input? Are there operators that are faster than others? Any idea about where I could find this information?

Any suggestion on the topic would be much appreciated. Thanks for your attention!

Best Regards,

  • $\begingroup$ By "speed-up the code" you mean "speed-up the quantum circuit construction on your CPU" or "speed-up the quantum circuit execution on the real chip"? $\endgroup$ Mar 8, 2022 at 12:36
  • $\begingroup$ I mean the quantum circuit execution on the real chip $\endgroup$
    – Vindem
    Mar 8, 2022 at 13:15

2 Answers 2


In order to speed up the response time of real IBM chips you have several options.

First, you can try to reduce the queue time by choosing to execute your algorithm on a chip that is not busy, i.e. with a low number of jobs in the queue. This is only a heuristic because other people with a higher priority might submit jobs while you are in the queue and increase your queue time. In order to pick the backend with the smallest queue:

from qiskit import IBMQ
from qiskit.providers.ibmq import least_busy

provider = None  # Replace with your provider
device = least_busy(
        filters=lambda x: x.configuration().n_qubits >= 3  # More than 3 qubits
        and not x.configuration().simulator                # Not a simulator
        and x.status().operational == True                 # Operational backend

The issue with queue time optimisation is that we do not know how IBM is computing the priority for each submissions, so it is hard to optimise.

As mentioned in another answer, Qiskit Runtime will drastically reduce the overall effect of queue time on your variational algorithm execution time (you do the queue only once instead of potentially hundreds of times).

Now about the actual circuit execution time, you have a lot of levers to improve that.

First, if the backend you are using supports dynamic repetition rate, you can easily have huge gains on a the execution time. An example I performed a few days ago validates this:

  • I performed a given experiment using the default rep_delay that was 250µs:

    backend.configuration().default_rep_delay == 0.00025  # Equality test on float is bad
  • I performed the exact same experiment, but this time with rep_delay = 0.00001 i.e. 10µs.

The experiment with rep_delay == 0.00001 executed 5 times faster.

The images below show the differences in execution time:

default rep_delay to 250µs rep_delay adapted to 10µs

To test if your backend supports dynamic rep_delay have a look at the value of backend.configuration().dynamic_reprate_enabled. If this is True, you can change the rep_delay when executing your circuits:

backend.run(circuits, rep_delay=0.00001)
execute(circuits, backend, rep_delay=0.00001)

A few remarks:

  • The rep_delay can theoretically be arbitrarily close to 0, but all your circuits should be executable in the rep_delay time frame, measurements included.
  • If your rep_delay is too short, you might encounter errors from the backend. If so, I recall that the advice was to increase rep_delay.
  • In theory, a smaller rep_delay leaves less time to the qubits to come back to their ground state, so you might experience higher SPAM errors when reducing the rep_delay. I am not aware of any study on these points though.
  • $\begingroup$ That looks interesting, thanks a lot! I will try that :) $\endgroup$
    – Vindem
    Mar 9, 2022 at 16:22

If you are currently not using Qiskit Runtime VQE program then you should.

Qiskit Runtime is a new execution model that markedly reduces IO overhead when submitting applications and algorithms to quantum processors that require many iterations of circuit executions and classical processing.

  • $\begingroup$ Thanks for your answer! Yes, I am currently using that, but I would like to know if there is a way to apply some tuning to further improve the code, depending on the hardware I am using. $\endgroup$
    – Vindem
    Mar 8, 2022 at 9:26
  • $\begingroup$ Hello! It seems like qiskit_runtime is depreciated. What is currently the optimum way to perform variational algorithms on hardware which accounts for queue waiting times? $\endgroup$ Feb 19 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.