-
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
Stop shuffling coupling map node indices in VF2 passes #13492
Merged
+38
−26
Merged
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
bdaff35
Stop shuffling coupling map node indices in VF2 passes
mtreinish aacc29e
Fix expected value in primitives test
mtreinish 293dafa
Merge remote-tracking branch 'origin/main' into vf2-in-order
mtreinish 0c8ccb8
Restore removed argument functionality and change default instead
mtreinish f3cfca7
Fix lint
mtreinish File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
Loading status checks…
Stop shuffling coupling map node indices in VF2 passes
This commit updates the preset pass manager construction usage of the VF2Layout and VF2PostLayout to stop shuffling the coupling map nodes by default. The theory behind the node shuffling is that since we limit the search space in the interest of runtime shuffling the node indices would change the search order to hopefully find a match that would be otherwise missed because we hit the internal state visit limit. However, this is showing in practice not to having a huge impact, especially since we're using the ordering heuristic from vf2++ that orders nodes by degree for the vf2 search. However, in the case of a circuit that was hardware efficient this can have the negative effect of making it harder for vf2 to find potential matches, especially on regular lattices. For example, in cases of a square grid lattice coupling map, and a path interaction graph (e.g. 0->1->2->3) the shuffling makes it much harder to find the mapping. This is because the lattice graphs the node degree is the same (or fall into the same few types of nodes) so the influence of the vf2++ heuristic isn't as significant and the index order has a larger impact because it is the search order for vf2. For smaller graphs this wasn't as noticeable but as devices scale up this effect has more of an impact. Since we rely solely on VF2 to find a perfect layout at higher optimization levels this shuffling is not desireable because we always want to find the perfect layout if it exists, especially for hardware efficient circuits that are constructed to not require swaps. So prioritizing the results for hardware efficient circuits is desireable by default. From an API impact perspective this doesn't change any of the interfaces or defaults for the VF2 passes in the interest of backwards compatibility. The only change is that this updates how we instantiate the VF2 passes to always use a deterministic node ordering independent of any user specified seed. This will be fully deterministic even in cases the user specifies a seed value for the transpilation, the output just might not be the same as before with the fixed seed; which is not guaranteed between releases.
commit bdaff355b1a89db3738a9983e91692188dcc4953
There are no files selected for viewing
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
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
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.
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.
Lint caught that the
seed_transpiler
argument ofgenerate_routing_passmanager
is not being used anymore. We should probably not have it as an input argument if it's not going to be used, but I feel like this might make the change more... permanent? We at least should make sure we want to stick to the fixed seed. On the other hand, I've checked and it looks likegenerate_routing_passmanager
is not part of the public API, so technically we could remove the argument without deprecation, but I see this as another argument to leave this PR for 2.0.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 unfortunately a public function: https://docs.quantum.ibm.com/api/qiskit/transpiler_preset#generate_routing_passmanager so we can't just change it. We could in 2.0 with an appropriate deprecation added in 1.4. Personally for this case if we were to include it in 1.3 I'd just disable the lint with a comment about preserving the signature.
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 opted to restore this argument's functionality and instead change the default to
-1
to not use any randomization. Since we're in 2.0 I figured a change in default was the least bad option here. I'm still not convinced there is a use case where the randomization is actually helping because in all the testing I've done it only just makes it harder for vf2 to find matches, but I can understand people wanting to experiment with this and it's why I didn't remove it from the pass itself.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 think this approach makes sense!