Stop shuffling coupling map node indices in VF2 passes #13685
Merged
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
|
One or more of the following people are relevant to this code:
|
mtreinish
force-pushed
the
backport-no-shuffle-vf2
branch
2 times, most recently
from
a1b80a8 to
df70b12
Compare
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 desirable 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 desirable by default. Especially since most connectivity graphs are lattices and will exhibit the negative impacts for hardware efficient circuits. 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. This is a partial backport of Qiskit#13492 without the API implications on the generate function from the original PR because that is only valid for 2.0. The change in what the preset pass managers do when running VF2 is valid though because it doesn't change our API guarantees around the transpilation, it just increases the likelihood of a match being found.
mtreinish
force-pushed
the
backport-no-shuffle-vf2
branch
from
df70b12 to
5af2173
Compare
Merged
ElePT
approved these changes
Jan 20, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
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 desirable 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 desirable by default. Especially since most connectivity graphs are lattices and will exhibit the negative impacts for hardware efficient circuits.
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.
Details and comments
This is a partial backport of #13492 without the API implications on the generate function from the original PR because that is only valid for 2.0. The change in what the preset pass managers do when running VF2 is valid though because it doesn't change our API guarantees around the transpilation, it just increases the likelihood of a match being found.