-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Fix InverseCancellation runtime performance regression #11278
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In Qiskit#11211, which was intended to improved the performance of the InverseCancellation pass, actually introduced a regression. This was because of the bugfix that was bundled in that PR to ensure we were checking parameter values for gates were correct. This check was done by doing a direct gate object equality between the self inverse gate selected and the gate object found in a run. This however was unecessary overhead as `Instruction.__eq__` has a large amount of overhead to compare gate equality more generally. In the context of a transpiler pass we can make assumptions that any gate with a given name is the same and directly compare the parameters if the names match the inverse pair. This will speed up the equality comparison for inverse pairs and fix the regression.
mtreinish
added
performance
Changelog: None
Do not include in changelog
mod: transpiler
Issues and PRs related to Transpiler
labels
Nov 19, 2023
One or more of the the following people are requested to review this:
|
mtreinish
changed the title
Fix InverseGateCancellation runtime performance regression
Fix InverseCancellation runtime performance regression
Nov 19, 2023
Pull Request Test Coverage Report for Build 6922729181
💛 - Coveralls |
I ran asv on the benchmarks that were flagged as causing a regression with this applied:
|
This should be superseded by #11370 which should fix the performance regression but is more general. I'll run some performance numbers before closing this to confirm the issue is fixed by that instead. |
1 task
Closing this as superseded by: #11370 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Changelog: None
Do not include in changelog
mod: transpiler
Issues and PRs related to Transpiler
performance
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
In #11211, which was intended to improved the performance of the InverseCancellation pass, actually introduced a regression. This was because of the bugfix that was bundled in that PR to ensure we were checking parameter values for gates were correct. This check was done by doing a direct gate object equality between the self inverse gate selected and the gate object found in a run. This however was unecessary overhead as
Instruction.__eq__
has a large amount of overhead to compare gate equality more generally. In the context of a transpiler pass we can make assumptions that any gate with a given name is the same and directly compare the parameters if the names match the inverse pair. This will speed up the equality comparison for inverse pairs and fix the regression.Details and comments