Qiskit / qiskit

Qiskit is an open-source SDK for working with quantum computers at the level of extended quantum circuits, operators, and primitives.
https://www.ibm.com/quantum/qiskit
Apache License 2.0
5.21k stars 2.36k forks source link

scaling analysis of qiskit for circuit size #7103

Open ewinston opened 3 years ago

ewinston commented 3 years ago

What is the expected enhancement?

As the performance of the hardware continually improves there is greater interest in ensuring qiskit can build and transpile circuits for those larger targets. This involves both ensuring the transpilation time doesn't take too long and the system memory usage isn't too large.

This issue is to track some of the work being done to look at how qiskit scales with circuit size.

Issue #6630 can be considered a case of this issue.

ewinston commented 3 years ago

As an example from a WIP look at the performance of building and transpiling a quantum volume circuit and transpiling it at various optimization levels assuming square connectivity.

test_circuit_scaling.TestProfileRandomCircuits.test_profile_qv_compile_square_opt_all.pdf

Here is an early attempt at profiling all transpiler passes for a square lattice. If the total time spent within the function is less 0.001 s the point is not shown in the plot since this is less than the precision of reporting. In some cases transpiler passes were not called with more typical options so may not reflect real world performance. The first page shows top passes taking the most time with this caveat. If the individual pass is not shown in the file no attempt was made to profile it (it may have required specific initialization parameters). It was run for commit b757914.

test_circuit_scaling.TestProfileTranspilerPasses.test_qv_run_pass_all.pdf

Call graphs are available from the profiing data. For instance for the template optimization pass test_circuit_scaling.TestProfileTranspilerPasses.test_qv_run_pass_335_TemplateOptimization_128_dot.pdf

eliarbel commented 3 years ago

Another aspect to look for is the construction time of the circuits. Working on randomized benchmarking experiments for qiskit-experiments we've encountered performance issues related to QuantumCircuit, e.g. with the append method calling to_instruction on the spot. Another big time consumer was deep-copying many objects during circuit construction. This issue might be relevant and offer some remedy: #4700.

ewinston commented 3 years ago

@eliarbel I profiled the scaling behavior of building single qubit RB circuits of,

        self.lengths = np.arange(1, 1000, 100)
        num_samples = 10
        seed = 1010
        qubits = range(n_qubits)
        for qubit in qubits:
            exp = StandardRB([qubit], self.lengths, num_samples=num_samples, seed=seed)
            circuits = exp.circuits()

Although the time to build these circuits seemed slow the scaling behavior was actually linear in the number of qubits benchmarked.

image

rht commented 2 years ago

Note that the transpilation/decomposition is already taking a long time, even with smaller circuits.

I benchmarked the elapsed time for transpilation and run for a circuit containing a controlled RealAmplitudes(nqubits, reps=4, entanglement="linear") and compare with the same implementation in Cirq. The result is that Cirq is much faster (I don't know how to separate transpilation and run in Cirq, so I can only plot the combined elapsed time). out_ansatz