-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Oxidize UnitarySynthesis
path using basis_gates
#13704
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
Conversation
UnitarySynthesis
path using basis_gates
, remove use of BackendV1
in testsUnitarySynthesis
path using basis_gates
Pull Request Test Coverage Report for Build 13369594575Details
💛 - Coveralls |
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 taken a quick look at the PR, and it seems to be in a very good shape. I have left a few minor questions, and will take a deeper look once the PRs it's based on are merged. And of course you are missing release notes.
)?; | ||
let out_qargs = dag.get_qargs(packed_instr.qubits); | ||
apply_synth_dag(py, &mut out_dag, out_qargs, &synth_dag)?; | ||
if basis_gates.is_empty() && matches!(target, None) { |
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.
Minor question: is there a benefit of writing matched!(target, None)
over target.is_none()
?
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 don't think so, this was me just being rusty in Rust when I wrote it :) I actually prefer target.is_none()
Removing |
68740c5
to
20fb3ae
Compare
20fb3ae
to
f9b93cc
Compare
One or more of the following people are relevant to this code:
|
… in logic, add comments and docstrings
0200fd2
to
35c24a2
Compare
…te logic from UnitarySynthesis pass. This plugin is currently ONLY USED as a fallback method if a custom unitary synthesis plugin is provided and fails. We don't have any unit tests currently covering this scenario. For more context, the _run_main_loop method in UnitarySynthesis has been replaced by a Rust function when the plugin is set to default.
35c24a2
to
7a1914c
Compare
Sorry @alexanderivrii if I have complicated the review with the last couple of commits. It might look like a lot of changes but I mostly moved around existing code (the one you already reviewed). As a summary:
For reference, the Python |
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.
@ElePT - thanks for refactoring the unitary_synthesis.rs
code, as well as separating unitary_synthesis.py
and the DefaultUnitarySynthesis
plugin.
So it seems that the plugin is not being tested, and also behaves differently than the UnitarySynthesis
pass?
if euler_basis_set.basis_supported(EulerBasis::U3) | ||
&& euler_basis_set.basis_supported(EulerBasis::U321) | ||
{ | ||
euler_basis_set.remove(EulerBasis::U3); |
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.
what happens if a user provides both 'U' and 'U3'?
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.
They are both included in the target euler_basis_set
and given to the 1q decomposer to deal with.
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.
if euler_basis_set.basis_supported(EulerBasis::U3) == true
and if euler_basis_set.basis_supported(EulerBasis::U) == true
should we remove one of them?
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.
This part of the code literally follows the logic from the 1q euler decomposer... I am not sure if there was an initial motivation not to remove one of the two (U/U3) or if it was an oversight. I can't think of a reason from the top of my head.
Thanks @ShellyGarion, I guess that the strictly correct thing here would be to duplicate the synthesis unit tests for the plugin. I can do that. |
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 @ElePT, I have carefully reviewed the code and it looks perfect to me, either because it truly is or because I lack the expertise to spot any issues, probably both are true :).
One question (and I have a feeling that I may have already asked it at some point, but then forgot the answer) is why we need some code duplication between rust and python sides, i.e. why can't DefaultSynthesisPlugin
just call the relevant functionality implemented in rust? I might be missing something even more basis here, doesn't UnitarySynthesis pass by default call the DefaultSynthesisPlugin?
And special thanks adding code comments, this helped me a lot to understand what each different function does.
I am approving it, but I think there were also some review comments from @ShellyGarion.
Thanks @alexanderivrii! To answer your question, the code shouldn't be duplicated. The reason why it is is that at the time the unitary synthesis code was originally oxidized, we didn't have any reference of how to interact with the plugin infrastructure, and because we only had 1 unitary synthesis plugin (the infrastructure wasn't really taken advantage of), we went for the path of replicating the whole flow in rust. In hindsight it would be way more modular to have only the plugin |
Adding the plugin unit tests will probably take a bit more effort than originally planned. If you are fine with merging the PR as-is, I can address the test situation in a follow-up (it's anyways a non user-facing change). |
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.
LGTM. Thanks!
Summary
This PR is a compilation of small improvements to the
UnitarySynthesis
pass, including:Performance -> Addition of fast path (Rust) for the use case where
target is None
, all input combinations can now be run using the fast path.Fixes -> Fixed an oversight where the
pulse_optimize
argument wasn't added to the fast path and therefore ignored (discovered after expanding the unit tests).These set the stage for future refactorings of the
UnitarySynthesis
class to take better advantage of the plugin model (the default plugin is currently ignored in the fast path).Note that this PR touches on code that is currently actively worked on in:
UnitarySynthesis
transpiler pass #13568And builds on top of #13706 (will need to be rebased after it's merged).
Details and comments