Open mtreinish opened 6 months ago
Now that #12004 has been implemented the XX decomposer is potentially the slowest part of optimization level 3 transpile. I ran a 100 qubit QV with a depth of 30 and generated this profile using main:
The highlighted section that takes 46.6 seconds is the time spent in the XXDecomposer and it's taking ~50% of the total transpile time.
I generated that profile by running the following under cprofile:
import time
from qiskit import transpile
from qiskit.transpiler import CouplingMap
from qiskit.providers.fake_provider import GenericBackendV2
from qiskit.circuit.library import QuantumVolume
cmap = CouplingMap.from_heavy_hex(19)
backend = GenericBackendV2(len(cmap.graph), coupling_map=cmap, basis_gates=['cx', 'rz', 'sx', 'x', 'id'])
qc = QuantumVolume(100, depth=30)
qc.measure_all()
start = time.perf_counter()
transpile(qc, backend, optimization_level=3)
stop = time.perf_counter()
print(stop - start)
The xxdecomposer should be sped up, but for that basis set it seems like we shouldn't be calling it at all since the only xx class gate available is cx and the twoqubitbasisdecomposer should be giving optimal decomposition for that already?
Hmm, that's a good point let me look at the UnitarySynthesis
pass's default plugin and see why it's running the XX decomposer at all. There very likely is a logic bug in the pass for figuring out which decomposer to run in the Target
path. The basis_gates
list path is very simple it only runs XXDecomposer
if rzx
is in the basis gates.
Just in general it would probably be nice UnitarySynthesis
would do some logging about what decomposers it's trying and why.
In the default 2q unitary synthesis plugin we use the
TwoQubitBasisDecomposer
and theXXDecomposer
based on the target (both the basis and fidelities). To finish #8774 and have a parallel rust implementation of the default synthesis plugin we need to port theXXDecomposer
class and likely the entireqiskit/synthesis/two_qubit/xx_decompose
subpackage to rust.