Stop shuffling coupling map node indices in VF2 passes #13492
Conversation
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.
mtreinish
added
Changelog: None
|
One or more of the following people are relevant to this code:
|
mtreinish
added
the
stable backport potential
There was a problem hiding this comment.
Thanks for looking into the regressions! I am weary of including this PR in the 1.3.0 release. I know we have included similar PRs in 1.3, but I also think that we already have a lot of (sometimes unintended) behavioral changes in the transpiler as a side effect of the migration to Rust, and it would be better to let the dust settle before introducing a last-minute one. The breaking unit test serves as a bit of confirmation for my suspicions, although I admit that the design of those backend estimator tests is improvable, they kind of rely on non-guaranteed behaviors.
| @@ -358,7 +358,7 @@ def _swap_condition(property_set): | |||
| target, | |||
| coupling_map, | |||
| backend_properties, | |||
| seed_transpiler, | |||
There was a problem hiding this comment.
Lint caught that the seed_transpiler argument of generate_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 like generate_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.
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.
I'm fine deferring it until 2.0, that would be my normal inclination for something like this. The only reason I proposed it as something to potentially include is that I haven't come across a situation this makes quality worse and it also makes vf2 more deterministic and predictable in the preset pass managers. For 2.0 I might refactor this to just remove the randomization feature from the passes altogether.
At least in this case I didn't catch the failure because I didn't run the tests locally with aer installed. The issue is that vf2 is finding better qubits now and the fidelity is slightly better than before so the expected expectation value has changed (the ideal result is -1 and after this change it's closer now). Personally I view this as kind of a fix/improvement this PR is supposed to cause, although in this case it's mostly anecdotal. |
mtreinish
removed
the
stable backport potential
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