Sabre layout and routing transpiler passes#4537
Merged
Merged
Conversation
Contributor
|
It looks good to me. |
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
1ucian0
reviewed
Jun 19, 2020
Co-authored-by: Gushu Li <Skywalker2012@users.noreply.github.com>
1ucian0
reviewed
Jun 20, 2020
1ucian0
reviewed
Jun 20, 2020
Co-authored-by: Luciano Bello <luciano.bello@ibm.com>
Co-authored-by: Luciano Bello <luciano.bello@ibm.com>
1ucian0
reviewed
Jun 21, 2020
1ucian0
reviewed
Jun 21, 2020
1ucian0
approved these changes
Jun 23, 2020
ajavadia
added
the
Changelog: Added
faisaldebouni
pushed a commit
to faisaldebouni/qiskit-terra
that referenced
this pull request
Aug 5, 2020
* add SABRE swap pass * add SABRE layout bidirectional search pass * expose sabre via preset passmanagers * undo deprecation for Layout.combine_into_edge_map * add Approx2qDecompose and SimplifyU3 passes * allow synthesis_fidelity in global transpile options * stopgap fix for circuits with regs in sabre_layout * add test * add tests * clean up sabre swap * restore lost qasm test files * fix tests * leave SimplifyU3 for later * leave Approx2qDecompose for later * Release notes Co-authored-by: Gushu Li <Skywalker2012@users.noreply.github.com> * lint * update level 3 * lint * lint relax * regenerate mapper tests * make set to list conversion deterministic * cleaning the diff a bit * test.python.transpiler.test_coupling.CouplingTest.test_make_symmetric * make randomization of SabreSwap controllable via seed * control randomization of SabreSwap via seed * move imports * test.python.transpiler.test_coupling.CouplingTest.test_neighbors * test.python.dagcircuit.test_dagcircuit.TestDagNodeSelection.test_front_layer * fix doc * Update test/python/transpiler/test_sabre_swap.py Co-authored-by: Luciano Bello <luciano.bello@ibm.com> * Update qiskit/transpiler/passes/routing/sabre_swap.py Co-authored-by: Luciano Bello <luciano.bello@ibm.com> * add note and test for neighbors * lint * release note Co-authored-by: Gushu Li <Skywalker2012@users.noreply.github.com> Co-authored-by: Luciano Bello <luciano.bello@ibm.com>
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Sep 1, 2023
The custom `decay` heuristic is supposed to penalise increases in depth in the output. The output space of qubits are the physical qubits, so the depth is defined in relation to those. Since its introduction in Qiskitgh-4537, this heuristic has instead been tracking the depth on the virtual qubits, which due to the swaps is not necessarily related to the depth in the output. Notably, this commit actually makes the depth for routing large volumetric circuits slightly _worse_ on average (at least for heavy-hex topologies). This may be because the effect on the heuristic is overweighted, or that the depth tracking resets after each gate is routed (and occasionally in between) to be flat across all qubits, rather than reflecting the actual depth each qubit is subject to.
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Sep 5, 2023
The custom `decay` heuristic is supposed to penalise increases in depth in the output. The output space of qubits are the physical qubits, so the depth is defined in relation to those. Since its introduction in Qiskitgh-4537, this heuristic has instead been tracking the depth on the virtual qubits, which due to the swaps is not necessarily related to the depth in the output. Notably, this commit actually makes the depth for routing large volumetric circuits slightly _worse_ on average (at least for heavy-hex topologies). This may be because the effect on the heuristic is overweighted, or that the depth tracking resets after each gate is routed (and occasionally in between) to be flat across all qubits, rather than reflecting the actual depth each qubit is subject to.
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Sep 5, 2023
The custom `decay` heuristic is supposed to penalise increases in depth in the output. The output space of qubits are the physical qubits, so the depth is defined in relation to those. Since its introduction in Qiskitgh-4537, this heuristic has instead been tracking the depth on the virtual qubits, which due to the swaps is not necessarily related to the depth in the output. Notably, this commit actually makes the depth for routing large volumetric circuits slightly _worse_ on average (at least for heavy-hex topologies). This may be because the effect on the heuristic is overweighted, or that the depth tracking resets after each gate is routed (and occasionally in between) to be flat across all qubits, rather than reflecting the actual depth each qubit is subject to.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Sep 7, 2023
The custom `decay` heuristic is supposed to penalise increases in depth in the output. The output space of qubits are the physical qubits, so the depth is defined in relation to those. Since its introduction in gh-4537, this heuristic has instead been tracking the depth on the virtual qubits, which due to the swaps is not necessarily related to the depth in the output. Notably, this commit actually makes the depth for routing large volumetric circuits slightly _worse_ on average (at least for heavy-hex topologies). This may be because the effect on the heuristic is overweighted, or that the depth tracking resets after each gate is routed (and occasionally in between) to be flat across all qubits, rather than reflecting the actual depth each qubit is subject to.
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Aug 14, 2025
Ever since Sabre was first introduced to Qiskit (in [1]), the extended set has been recalculated from the front layer, every time the front layer is updated. Now that the extended set is tracked as a series of layers, it is easily possible to keep the layer structure updated in the same way as the front layer, by tracking separate points in the topological iteration through the interaction graph. To speed up synchronisation of the layers during updates, a new outer tracker, `Layers`, now means that a removal can jump immediately to the correct layer, without having to test multiples. This outer structure co-operates with the individual layers to effect faster lookups and removals; rather than each layer storing its own `IndexMap`, they instead store only a `Vec`, and the outer `Layers` tracks _where_ in the `Vec` any given gate is. On removal, the layer returns which, if any, gate has moved to occupy the otherwise empty slot (since removals are by swap, not shift). This avoids all hash lookups in the layer structures; everything is simple contiguous indexed access. With the tracking done elsewhere, and with `VecMap` providing type-safe indexing, each individual `Layer` now stores its contained gates in terms of `[VirtualQubit; 2]`; this minimises the amount of data that needs to be modified on a swap, at the cost that actions that need to associate actual gates with the current physical qubits (like iterating over active swaps) now need access to the `NLayout`, rather than the layout being (implicitly) tracked by each `Layer` via `apply_swap`. This is a performance improvement; as more overhead is reduced, the cost of the hash lookups in swap application was ever more visible. [1]: fab61d2: Sabre layout and routing transpiler passes (Qiskitgh-4537)
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Mar 11, 2026
Ever since Sabre was first introduced to Qiskit (in [1]), the extended set has been recalculated from the front layer, every time the front layer is updated. Now that the extended set is tracked as a series of layers, it is easily possible to keep the layer structure updated in the same way as the front layer, by tracking separate points in the topological iteration through the interaction graph. To speed up synchronisation of the layers during updates, a new outer tracker, `Layers`, now means that a removal can jump immediately to the correct layer, without having to test multiples. This outer structure co-operates with the individual layers to effect faster lookups and removals; rather than each layer storing its own `IndexMap`, they instead store only a `Vec`, and the outer `Layers` tracks _where_ in the `Vec` any given gate is. On removal, the layer returns which, if any, gate has moved to occupy the otherwise empty slot (since removals are by swap, not shift). This avoids all hash lookups in the layer structures; everything is simple contiguous indexed access. With the tracking done elsewhere, and with `VecMap` providing type-safe indexing, each individual `Layer` now stores its contained gates in terms of `[VirtualQubit; 2]`; this minimises the amount of data that needs to be modified on a swap, at the cost that actions that need to associate actual gates with the current physical qubits (like iterating over active swaps) now need access to the `NLayout`, rather than the layout being (implicitly) tracked by each `Layer` via `apply_swap`. This is a performance improvement; as more overhead is reduced, the cost of the hash lookups in swap application was ever more visible. [1]: fab61d2: Sabre layout and routing transpiler passes (Qiskitgh-4537)
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Mar 11, 2026
Ever since Sabre was first introduced to Qiskit (in [1]), the extended set has been recalculated from the front layer, every time the front layer is updated. Now that the extended set is tracked as a series of layers, it is easily possible to keep the layer structure updated in the same way as the front layer, by tracking separate points in the topological iteration through the interaction graph. To speed up synchronisation of the layers during updates, a new outer tracker, `Layers`, now means that a removal can jump immediately to the correct layer, without having to test multiples. This outer structure co-operates with the individual layers to effect faster lookups and removals; rather than each layer storing its own `IndexMap`, they instead store only a `Vec`, and the outer `Layers` tracks _where_ in the `Vec` any given gate is. On removal, the layer returns which, if any, gate has moved to occupy the otherwise empty slot (since removals are by swap, not shift). This avoids all hash lookups in the layer structures; everything is simple contiguous indexed access. With the tracking done elsewhere, and with `VecMap` providing type-safe indexing, each individual `Layer` now stores its contained gates in terms of `[VirtualQubit; 2]`; this minimises the amount of data that needs to be modified on a swap, at the cost that actions that need to associate actual gates with the current physical qubits (like iterating over active swaps) now need access to the `NLayout`, rather than the layout being (implicitly) tracked by each `Layer` via `apply_swap`. This is a performance improvement; as more overhead is reduced, the cost of the hash lookups in swap application was ever more visible. [1]: fab61d2: Sabre layout and routing transpiler passes (Qiskitgh-4537)
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Mar 24, 2026
Ever since Sabre was first introduced to Qiskit (in [1]), the extended set has been recalculated from the front layer, every time the front layer is updated. Now that the extended set is tracked as a series of layers, it is easily possible to keep the layer structure updated in the same way as the front layer, by tracking separate points in the topological iteration through the interaction graph. To speed up synchronisation of the layers during updates, a new outer tracker, `Layers`, now means that a removal can jump immediately to the correct layer, without having to test multiples. This outer structure co-operates with the individual layers to effect faster lookups and removals; rather than each layer storing its own `IndexMap`, they instead store only a `Vec`, and the outer `Layers` tracks _where_ in the `Vec` any given gate is. On removal, the layer returns which, if any, gate has moved to occupy the otherwise empty slot (since removals are by swap, not shift). This avoids all hash lookups in the layer structures; everything is simple contiguous indexed access. With the tracking done elsewhere, and with `VecMap` providing type-safe indexing, each individual `Layer` now stores its contained gates in terms of `[VirtualQubit; 2]`; this minimises the amount of data that needs to be modified on a swap, at the cost that actions that need to associate actual gates with the current physical qubits (like iterating over active swaps) now need access to the `NLayout`, rather than the layout being (implicitly) tracked by each `Layer` via `apply_swap`. This is a performance improvement; as more overhead is reduced, the cost of the hash lookups in swap application was ever more visible. [1]: fab61d2: Sabre layout and routing transpiler passes (Qiskitgh-4537)
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Apr 8, 2026
Ever since Sabre was first introduced to Qiskit (in [1]), the extended set has been recalculated from the front layer, every time the front layer is updated. Now that the extended set is tracked as a series of layers, it is easily possible to keep the layer structure updated in the same way as the front layer, by tracking separate points in the topological iteration through the interaction graph. To speed up synchronisation of the layers during updates, a new outer tracker, `Layers`, now means that a removal can jump immediately to the correct layer, without having to test multiples. This outer structure co-operates with the individual layers to effect faster lookups and removals; rather than each layer storing its own `IndexMap`, they instead store only a `Vec`, and the outer `Layers` tracks _where_ in the `Vec` any given gate is. On removal, the layer returns which, if any, gate has moved to occupy the otherwise empty slot (since removals are by swap, not shift). This avoids all hash lookups in the layer structures; everything is simple contiguous indexed access. With the tracking done elsewhere, and with `VecMap` providing type-safe indexing, each individual `Layer` now stores its contained gates in terms of `[VirtualQubit; 2]`; this minimises the amount of data that needs to be modified on a swap, at the cost that actions that need to associate actual gates with the current physical qubits (like iterating over active swaps) now need access to the `NLayout`, rather than the layout being (implicitly) tracked by each `Layer` via `apply_swap`. This is a performance improvement; as more overhead is reduced, the cost of the hash lookups in swap application was ever more visible. [1]: fab61d2: Sabre layout and routing transpiler passes (Qiskitgh-4537)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Adding a layout and routing method from https://arxiv.org/abs/1809.02573 (by @skywalker2012).
The initial layout selection is especially good in this method and finds high-quality initial placements very fast. I allow this layout method to be combined with any of the other available routing methods as well through selection of
layout_methodandrouting_method. But Sabre's own routing method is also quite good - it anticipates upcoming gates via look ahead, and gives you the ability to trade off parallelism vs. number of gates.I have not made this part of the default pipeline yet, but I think I'll do that once I do more randomized testing.