Expose internal rust interface to DenseLayout #12104
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
This commit makes a small change to the rust code for DenseLayout that enables calling it more easily from rust. The primary obstacle was the pyfunction used PyReadonlyArray2<f64> inputs which precludes calling it with rust constructed Array2Views<f64>. This adds a new inner public function which takes the array view directly and then the pyfunction's only job is to convert the inputs and outputs to Python. The python side of the function is still building a sparse matrix and then runs reverse Cuthill–McKee to get a permutation of the densest subgraph so any rust consumers will want to keep that in mind (and maybe use sprs to do the same). At the same time it corrects an oversight in the original implementation where the returned numpy arrays of the densest subgraph are copied instead of being returned as references. This should slightly improve performance by eliminating 3 array copies that weren't needed.
mtreinish
added
priority: low
Changelog: None
|
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 9194248015Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
jakelishman
reviewed
Apr 3, 2024
There was a problem hiding this comment.
This looks fine to me. Do either of these functions actually need to return PyResult? They both appear to be infallible.
Let's do this after #12121 merges, though, since there's a couple of tweaks that'll be needed.
|
No, the |
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
May 22, 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
henryzou50
reviewed
May 22, 2024
henryzou50
approved these changes
May 22, 2024
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
May 22, 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
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 22, 2024
Building on the work done in #10829, #10721, and #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 #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 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: #12104
ElePT
pushed a commit
to ElePT/qiskit
that referenced
this pull request
May 31, 2024
* Expose internal rust interface to DenseLayout This commit makes a small change to the rust code for DenseLayout that enables calling it more easily from rust. The primary obstacle was the pyfunction used PyReadonlyArray2<f64> inputs which precludes calling it with rust constructed Array2Views<f64>. This adds a new inner public function which takes the array view directly and then the pyfunction's only job is to convert the inputs and outputs to Python. The python side of the function is still building a sparse matrix and then runs reverse Cuthill–McKee to get a permutation of the densest subgraph so any rust consumers will want to keep that in mind (and maybe use sprs to do the same). At the same time it corrects an oversight in the original implementation where the returned numpy arrays of the densest subgraph are copied instead of being returned as references. This should slightly improve performance by eliminating 3 array copies that weren't needed. * Remove PyResult --------- Co-authored-by: Henry Zou <87874865+henryzou50@users.noreply.github.com>
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
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 makes a small change to the rust code for DenseLayout that enables calling it more easily from rust. The primary obstacle was the pyfunction used PyReadonlyArray2 inputs which precludes calling it with rust constructed Array2Views. This adds a new inner public function which takes the array view directly and then the pyfunction's only job is to convert the inputs and outputs to Python. The python side of the function is still building a sparse matrix and then runs reverse Cuthill–McKee to get a permutation of the densest subgraph so any rust consumers will want to keep that in mind (and maybe use sprs to do the same).
At the same time it corrects an oversight in the original implementation where the returned numpy arrays of the densest subgraph are copied instead of being returned as references. This should slightly improve performance by eliminating 3 array copies that weren't needed.
Details and comments