-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-qubit fusion #577
Multi-qubit fusion #577
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this implementation!
Everything looks good to me.
Do we need to add something in the doc?
I did more extensive benchmarks regarding this point and it seems that the slow performance for max_qubits > 2 is associated to both the multiqubit operators and the fusion algorithm. In particular, I tried extracting the fused circuit from qiskit and translating it to qibo and performance (second column below) is worse than qiskit but better than using qibo fusion: supremacy - max_qubits = 2
supremacy - max_qubits = 3
supremacy - max_qubits = 4
supremacy - max_qubits = 5
|
Codecov Report
@@ Coverage Diff @@
## master #577 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 86 86
Lines 12861 12926 +65
=========================================
+ Hits 12861 12926 +65
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Extends the
circuit.fuse()
to work with more than two qubits in the fused gates. The maximum number of qubits in aFusedGate
is passed as argument incircuit.fuse(max_qubits)
.Here are some benchmarks comparing this with the two qubit fusion currently implemented in qibo:
variational - cupy
supremacy - cupy
variational - numba
supremacy - numba
where we see that the two-qubit fusion performance remains the same as master. Here is a comparison to qiskit using max_qubits>=2:
supremacy - max_qubits = 2
supremacy - max_qubits = 3
supremacy - max_qubits = 4
supremacy - max_qubits = 5
where we see that we do not get improvement when using max_qubits > 2, in contrast to other libraries (qiskit, qsim). This is more likely associated to qiboteam/qibojit#51 about multi-qubit custom operators.
Regardless, I believe that this PR is useful to have since it doesn't affect any current feature (two-qubit fusion performance remains the same) and enables higher order fusion, even if it is not really optimized. If we improve the multi-qubit operators in qibojit, hopefully this will work better.