-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port star_preroute
to rust (backport #12761)
#12846
Conversation
* This commit ports the core logic of `star_preroute` from Python to Rust. The changes involve creating a new Rust module for the star prerouting algorithm and updating the corresponding Python code to integrate with this new Rust functionality. Details: - New Rust file: Added `star_preroute.rs` to handle the core logic of the function `star_preroute` from the python side. This file defines the type aliases for node and block representations, which matches the current block representation of the `StarBlock` (except that the center is just a bool, as we only need to know if there is a center), and the node representation matches how the nodes used in `SabreDAG`. The `star_preroute` function processes the star blocks witihin the `SabreDAG` and finds the linear routing equivalent and then returns the result as a `SabreResult`. Thus we can use the same methods we used in Sabre, such as `_build_sabre_dag` and `_apply_sabre_result`. - Node representation: A key part of this implementation is how it takes advantage of `SabreResult` and `SabreDAG`, so the node representation is a tuple of the node id, list of qubit indices, a set of classical bit indices, and a directive flag. However, once we update the regular DAG to rust, this part may change significantly. - Updates in the SABRE rust module: To use `sabre_dag.rs` and `swap_map.rs` in `star_prerouting`, I change them to be public in `crates/accelerate/src/sabre/mod.rs`. Not sure if it makes more sense to do it this way or to move `star_prerouting` to `crates/accelerate/src/sabre/` since it mimics the methods used in Sabre to change the dag. - Python side updates: Imported the necessary modules and only modified the function `star_preroute` so that now the function performs the heavy lifting of transforming the DAG within the Rust space, leveraging `_build_sabre_dag` and `_apply_sabre_result`. - Possible issues: I was not sure how correctly handle control flow from the rust side. I know that `route.rs` handles this with `route_control_flow_block` to populate the `node_block_results` for `SabreResult`, but I was not sure how to best take advantage of this function for `star_prerouting`. Currently, the `node_block_results` for `star_prerouting` essentially always empty and just there to have`SabreResult`. There also seems to be no unit tests for `star_prerouting` that includes control flow. * lint * Added additional test and adjust the swap map result - Added the additional test of qft linearization and that the resultings circuit has `n-2` swap gates where `n` is the number of cp gates. - Changed the `node_id` in `apply_swap` of `star_preroute.rs` to use the current node id as it is more efficient, but just does not match how we do it in Sabre. This makes it so that we apply the gate first then the swap, which fixes an error we had before where we never placed a swap gate at the end of the processing a block. This only affected tests where we had multiple blocks to process. To make sure we apply the results correctly from `SabreResult`, I added a flag to `_apply_sabre_result` to treat the case of `StarPrerouting` differently so that it applies the swap after applying the node. - Added a hasp map from node to block to make processing each node in the given processing order have `n + n` time complexity instead of `n^2`. As a result, we can also remove the function `find_block_id` * Reverted changes to `_apply_sabre_result` and fixed handling on rust side - Removed `apply_swap_first` flag in `_apply_sabre_result` as it did not make sense to have it as there are no other scenario where a user may want to have control over applying the swap first. - To adjust for this and make `star_preroute` consistent with `apply_sabre_result` to apply swaps before the node id on the swap map, I adjusted `star_preroute.rs` to first process the blocks to gather the swap locations and the gate order. Once we have the full gate order, we can use the swap locations to apply the swaps while knowing the `qargs` of the node before the swap and the `node_id` of the node after the swap. - Since the above in done in the main `star_preroute` function, I removed `qubit_ampping` and `out_map` as arguments for `process_blocks`. (cherry picked from commit b23c545) # Conflicts: # crates/pyext/src/lib.rs
Cherry-pick of b23c545 has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 10148101452Details
💛 - Coveralls |
Summary
Closes #12337
This PR ports the core logic of
star_preroute
from Python to Rust. The changes involve creating a new Rust module for the star prerouting algorithm and updating the corresponding Python code to integrate with this new Rust functionality.These changes only involve the first part of porting
star_prerouting
to rust, as it mainly handles porting the logic of transforming the DAG with the StarBlocks to rust, but we will still need to decide how we should port collecting the StarBlocks to rust. This is a bit more tricky as there are still ongoing discussion on how we can extend the block collection, such as in PR #12498 .Details and comments
star_preroute.rs
to handle the core logic of the functionstar_preroute
from the python side. This file defines the type aliases for node and block representations, which matches the current block representation of theStarBlock
(except that the center is just a bool, as we only need to know if there is a center), and the node representation matches how the nodes used inSabreDAG
. Thestar_preroute
function processes the star blocks witihin theSabreDAG
to finds the linear routing equivalent and then returns the result as aSabreResult
.SabreResult
andSabreDAG
, so the node representation is a tuple of the node id, list of qubit indices, a set of classical bit indices, and a directive flag. However, once we update the regular DAG to rust, this part may change significantly, but the main logic will remain unchanged.sabre_dag.rs
andswap_map.rs
instar_prerouting
, I change them to be public incrates/accelerate/src/sabre/mod.rs
. Not sure if it makes more sense to do it this way or to movestar_prerouting
tocrates/accelerate/src/sabre/
since it mimics the methods used in Sabre to change the dag.star_preroute
so that now the function performs the heavy lifting of transforming the DAG within the Rust space, leveraging_build_sabre_dag
and_apply_sabre_result
.route.rs
handles this withroute_control_flow_block
to populate thenode_block_results
forSabreResult
, but I was not sure how to best take advantage of this function forstar_prerouting
. Currently, thenode_block_results
forstar_prerouting
essentially always empty and just there to haveSabreResult
. There also seems to be no unit tests forstar_prerouting
that includes control flow.This is an automatic backport of pull request Port
star_preroute
to rust #12761 done by Mergify.