Commits on Nov 25, 2024

1. 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.

   

   mtreinish committed Nov 25, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for bdaff35
   • Browse repository at this point

   Copy the full SHA

   bdaff35 View commit details

   Browse the repository at this point in the history