-
Notifications
You must be signed in to change notification settings - Fork 361
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
Add Fusion variations #1110
Add Fusion variations #1110
Conversation
dbb6c26
to
e60275c
Compare
e60275c
to
34fec82
Compare
25841ca
to
88aa34f
Compare
88aa34f
to
5546e5a
Compare
d2959bf
to
ebe98bf
Compare
aaf9462
to
5e21688
Compare
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.
I leave a few comments, while we wait for Doi's PR. Looks like they are many, but a large fraction of them are just to add forgotten override
keyword.
f681afd
to
3cff8ab
Compare
#1149 will resolve fails in test. |
I think this needs rebasing to remove #1149 now that the bug fixes have been merged into master. Otherwise we need to wait for 1149 to be merged before this can be merged |
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.
I have a couple questions about diagonal param in fusion. The main one is if we are fusing a set of diagonal matrices, we should not use the unitary simulator since that is inefficient, but directly update the diagonal vector instead.
virtual bool support_diagonal() const = 0; | ||
|
||
// Aggregate a subcircuit of operations into a single operation | ||
virtual op_t generate_operation(std::vector<op_t>& fusioned_ops, bool diagonal = false) const { |
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.
Does diagonal mean all ops in fusioned_ops are diagonal, or that the output is diagonal even if the ops are not?
If its the first we should have a specialized simulation method that doesn't require building the full square matrix.
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.
It is the second because CNOT-diagonal-CNOT patttern is detected.
I implemented more efficient version to generate a diagonal matrix but performance improvement was very limited for generation of small diagonal matrix.
for (size_t i = 0; i < fusioned_op.qubits.size(); i++) | ||
fusioned_op.qubits[i] = remapped2orig[fusioned_op.qubits[i]]; | ||
|
||
if (diagonal) { |
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.
To continue from above comment. If all ops are diagonal, we should have generate_operation_internal
take the diagonal arg and return the diagonal operation if the method supports it.
public: | ||
virtual std::string name() override { return "superop"; }; | ||
|
||
virtual bool support_diagonal() const override { return false; } |
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.
We could add a diagonal_superop instruction for the density matrix / superop simulators
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.
That's true. I disabled for them to test only statevector first.
f8a57fc
to
829912b
Compare
Summary
Add fusion variations
Details and comments
Currently cost-based-fusion is an only method of fusion. This PR adds 1- and 2-Qubit fusion, which greedily fuse operations with consideration of commutativity in gate operations. To add them, this PR introduces
AER::Transpile::Fuser
, which is the base class of three fusion methods.