Add DenseLayout trial to SabreLayout
#12453
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
mtreinish
added
on hold
|
One or more of the following people are relevant to this code:
|
|
I ran some quick asv benchmarks with this: In this case it shows that at various scale the runtime overhead is neglible but in some cases the quality of output is greatly improved. The extra trial only takes effect in cases where it results in a better outcome. |
mtreinish
added
the
Rust
Pull Request Test Coverage Report for Build 9196491844Details
💛 - Coveralls |
henryzou50
approved these changes
May 22, 2024
There was a problem hiding this comment.
LGTM. It's great to see the positive impact of integrating the DenseLayout trial into SabreLayout. While we didn't see improvements in the other benchmarks for depth, the significant reduction in depth for QFT benchmarks is particularly impressive and promising. The negligible runtime overhead further reflects the efficiency of this approach. I'm excited to see how we can build on this improvement and explore other methods to further refine our layout selection strategy.
Building on the work done in Qiskit#10829, Qiskit#10721, and Qiskit#12104 this commit adds a new trial to all runs of `SabreLayout` that runs the dense layout pass. In general the sabre layout algorithm starts from a random layout and then runs a routing algorithm to permute that layout virtually where swaps would be inserted to select a layout that would result in fewer swaps. As was discussed in Qiskit#10721 and Qiskit#10829 that random starting point is often not ideal especially for larger targets where the distance between qubits can be quite far. Especially when the circuit qubit count is low relative to the target's qubit count this can result it poor layouts as the distance between the qubits is too large. In qiskit we have an existing pass, `DenseLayout`, which tries to find the most densely connected n qubit subgraph of a connectivity graph. This algorithm necessarily will select a starting layout where the qubits are near each other and for those large backends where the random starting layout doesn't work well this can improve the output quality. As the overhead of `DenseLayout` is quite low and the core algorithm is written in rust already this commit adds a default trial that uses DenseLayout as a starting point on top of the random trials (and any input starting points). For example if the user specifies to run SabreLayout with 20 layout trials this will run 20 random trials and one trial with `DenseLayout` as the starting point. This is all done directly in the sabre layout rust code for efficiency. The other difference between the standalone `DenseLayout` pass is that in the standalone pass a sparse matrix is built and a reverse Cuthill-McKee permutation is run on the densest subgraph qubits to pick the final layout. This permutation is skipped because in the case of Sabre's use of dense layout we're relying on the sabre algorithm to perform the permutation. Depends on: Qiskit#12104
mtreinish
force-pushed
the
dense-sabre-ftw
branch
from
06e208f
to
921a53c
Compare
ElePT
pushed a commit
to ElePT/qiskit
that referenced
this pull request
May 31, 2024
Building on the work done in Qiskit#10829, Qiskit#10721, and Qiskit#12104 this commit adds a new trial to all runs of `SabreLayout` that runs the dense layout pass. In general the sabre layout algorithm starts from a random layout and then runs a routing algorithm to permute that layout virtually where swaps would be inserted to select a layout that would result in fewer swaps. As was discussed in Qiskit#10721 and Qiskit#10829 that random starting point is often not ideal especially for larger targets where the distance between qubits can be quite far. Especially when the circuit qubit count is low relative to the target's qubit count this can result it poor layouts as the distance between the qubits is too large. In qiskit we have an existing pass, `DenseLayout`, which tries to find the most densely connected n qubit subgraph of a connectivity graph. This algorithm necessarily will select a starting layout where the qubits are near each other and for those large backends where the random starting layout doesn't work well this can improve the output quality. As the overhead of `DenseLayout` is quite low and the core algorithm is written in rust already this commit adds a default trial that uses DenseLayout as a starting point on top of the random trials (and any input starting points). For example if the user specifies to run SabreLayout with 20 layout trials this will run 20 random trials and one trial with `DenseLayout` as the starting point. This is all done directly in the sabre layout rust code for efficiency. The other difference between the standalone `DenseLayout` pass is that in the standalone pass a sparse matrix is built and a reverse Cuthill-McKee permutation is run on the densest subgraph qubits to pick the final layout. This permutation is skipped because in the case of Sabre's use of dense layout we're relying on the sabre algorithm to perform the permutation. Depends on: Qiskit#12104
This was referenced Jul 1, 2024
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Oct 23, 2024
Right now sabre layout uses n random trials (as specified by the user or defaulting to num_cpus) and since Qiskit#12453 one additional trial taking the qubits of the densest subgraph as a starting point. There are also a couple of other trivial examples to try which may or may not produce better results depending on the circuit, a trivial layout and a reverse trivial layout. In the case of a hardware efficient circuit the trivial layout will map exactly and would always be picked. When running in a preset pass manager sabre should never be called in this scenario because VF2Layout will find the mapping, but the incremental cost of adding the trial is minimal. Similarly the cost of a reversed trivial layout (where virtual qubit 0 -> n, 1 -> n - 1, etc.) is trivial and may in some scenarios produce a better results.
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Oct 23, 2024
Right now sabre layout uses n random trials (as specified by the user or defaulting to num_cpus) and since Qiskit#12453 one additional trial taking the qubits of the densest subgraph as a starting point. There are also a couple of other trivial examples to try which may or may not produce better results depending on the circuit, a trivial layout and a reverse trivial layout. In the case of a hardware efficient circuit the trivial layout will map exactly and would always be picked. When running in a preset pass manager sabre should never be called in this scenario because VF2Layout will find the mapping, but the incremental cost of adding the trial is minimal. Similarly the cost of a reversed trivial layout (where virtual qubit 0 -> n, 1 -> n - 1, etc.) is trivial and may in some scenarios produce a better results.
1 task
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 6, 2024
* Add more default trials to sabre layout Right now sabre layout uses n random trials (as specified by the user or defaulting to num_cpus) and since #12453 one additional trial taking the qubits of the densest subgraph as a starting point. There are also a couple of other trivial examples to try which may or may not produce better results depending on the circuit, a trivial layout and a reverse trivial layout. In the case of a hardware efficient circuit the trivial layout will map exactly and would always be picked. When running in a preset pass manager sabre should never be called in this scenario because VF2Layout will find the mapping, but the incremental cost of adding the trial is minimal. Similarly the cost of a reversed trivial layout (where virtual qubit 0 -> n, 1 -> n - 1, etc.) is trivial and may in some scenarios produce a better results. * Update layouts for failing tests * Add ring layouts for common connectivity graphs * Add release notes and docs * Apply suggestions from code review Co-authored-by: Elena Peña Tapia <[email protected]> * Fix lint --------- Co-authored-by: Elena Peña Tapia <[email protected]>
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
Building on the work done in #10829, #10721, and #12104 this commit adds
a new trial to all runs of
SabreLayoutthat runs the dense layoutpass. In general the sabre layout algorithm starts from a random layout
and then runs a routing algorithm to permute that layout virtually where
swaps would be inserted to select a layout that would result in fewer
swaps. As was discussed in #10721 and #10829 that random starting point
is often not ideal especially for larger targets where the distance
between qubits can be quite far. Especially when the circuit qubit count
is low relative to the target's qubit count this can result it poor
layouts as the distance between the qubits is too large. In qiskit we
have an existing pass,
DenseLayout, which tries to find the mostdensely connected n qubit subgraph of a connectivity graph. This
algorithm necessarily will select a starting layout where the qubits are
near each other and for those large backends where the random starting
layout doesn't work well this can improve the output quality.
As the overhead of
DenseLayoutis quite low and the core algorithm iswritten in rust already this commit adds a default trial that uses
DenseLayout as a starting point on top of the random trials (and any
input starting points). For example if the user specifies to run
SabreLayout with 20 layout trials this will run 20 random trials and
one trial with
DenseLayoutas the starting point. This is all donedirectly in the sabre layout rust code for efficiency. The other
difference between the standalone
DenseLayoutpass is that in thestandalone pass a sparse matrix is built and a reverse Cuthill-McKee
permutation is run on the densest subgraph qubits to pick the final
layout. This permutation is skipped because in the case of Sabre's
use of dense layout we're relying on the sabre algorithm to perform
the permutation.
Details and comments
Depends on: #12104
This PR is based on top of #12104 and will be manually rebased after that merges. You can look at: 06e208f for the details of just this PR.