More conservative caching in the CommutationChecker
#13600
+105
−31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #13570.
This PR might require some discussion on what assumptions we have on custom
Instruction
s. However, if we cannot assume that an instruction's definition is fully specified by it'sparams
, then we cannot use theparams
as key in the commutation library. (We also sometimes put additional information outside ofparams
.)This PR makes the commutation cache more conservative, by only additionally caching standard gate relations, where we know the instructions are defined by it's
params
.Details and comments
The commutation checker currently caches commutations of any instruction with float-only
params
(with some hardcoded exceptions). This leads to problems if the instruction's definition depends on more than just theparams
, e.g. we could have a custom gate defined asCalling the commutation checker with an instance of this gate will then cache the first commutation, under the key
[]
(since theparams
are empty) and subsequent queries of the cache return the first commutation, regardless of the evil rotation angle. For exampleAnother solution could be to explicitly state the assumption that the gate must be fully specified by the
params
attribute, and we'd have to update some gates in the library.I ran the
test/benchmarks/utility_scale.py
benchmarks and could not see a regression on my laptop.