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
IBMQ.load_account()
provider = None # Replace with your provider
device = least_busy(
provider.backends(
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:
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.
