You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed for some large circuits that changing the name of the qubit registers in the input circuit affects the final CX gate count and depth of the compiled circuit.
I compiled a 49 qubit circuit that has a CX gate between every pair of qubits onto a 7x7 grid multiple times. The first time I named the 49 qubit register 'q0', and each subsequent time I incremented the number, so the second time it was 'q1', then 'q2' and so on. Each time I compiled the circuit the resource counts were different. Other than the register name, the input circuit remains exactly the same each time, including the order that the CX gates appear in.
For qreg q0[49]: depth: 24 CX: 76 qubits: 49
For qreg q1[49]: depth: 43 CX: 75 qubits: 49
For qreg q2[49]: depth: 50 CX: 92 qubits: 49
For qreg q3[49]: depth: 44 CX: 94 qubits: 49
For qreg q4[49]: depth: 41 CX: 75 qubits: 49
For qreg q5[49]: depth: 39 CX: 91 qubits: 49
...
I also tried many other names, including names without numbers and the results kept changing. If I were to keep the same name and compile multiple times I get the same result every time.
This only seems to be happening with large circuits, and the disparity in the results seems to be larger for circuits with highly connected virtual qubits.
I compiled 'gf2^16_mult.qasm' from the Feynman repository onto the same grid, once as is and a second time with the register name changed from 'qubits' to 'qubits0' and got different results for both depth and number of qubits.
I generated the device using ./staq_device_generator -r 7 7 > device.json
and obtained the resource counts using ./staq -m -d device.json -l bestfit -M steiner -f resources circuit.qasm
The text was updated successfully, but these errors were encountered:
@Gurleenp, can you confirm the compiler options you were using so we can narrow down where the variances are occurring? The layout and mapping algorithms in particular are sensitive to qubit orderings, so I imagine that's where it's happening.
These results are from using steiner with bestfit, but it happens when I use steiner with any layout method. It never happens when I choose swap with any of the layout methods.
I noticed for some large circuits that changing the name of the qubit registers in the input circuit affects the final CX gate count and depth of the compiled circuit.
I compiled a 49 qubit circuit that has a CX gate between every pair of qubits onto a 7x7 grid multiple times. The first time I named the 49 qubit register 'q0', and each subsequent time I incremented the number, so the second time it was 'q1', then 'q2' and so on. Each time I compiled the circuit the resource counts were different. Other than the register name, the input circuit remains exactly the same each time, including the order that the CX gates appear in.
For
qreg q0[49]
:depth: 24 CX: 76 qubits: 49
For
qreg q1[49]
:depth: 43 CX: 75 qubits: 49
For
qreg q2[49]
:depth: 50 CX: 92 qubits: 49
For
qreg q3[49]
:depth: 44 CX: 94 qubits: 49
For
qreg q4[49]
:depth: 41 CX: 75 qubits: 49
For
qreg q5[49]
:depth: 39 CX: 91 qubits: 49
...
I also tried many other names, including names without numbers and the results kept changing. If I were to keep the same name and compile multiple times I get the same result every time.
This only seems to be happening with large circuits, and the disparity in the results seems to be larger for circuits with highly connected virtual qubits.
I compiled 'gf2^16_mult.qasm' from the Feynman repository onto the same grid, once as is and a second time with the register name changed from 'qubits' to 'qubits0' and got different results for both depth and number of qubits.
I generated the device using
./staq_device_generator -r 7 7 > device.json
and obtained the resource counts using
./staq -m -d device.json -l bestfit -M steiner -f resources circuit.qasm
The text was updated successfully, but these errors were encountered: