Skip to content
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

Rework preset pass mangers levels #7112

Open
mtreinish opened this issue Oct 8, 2021 · 3 comments
Open

Rework preset pass mangers levels #7112

mtreinish opened this issue Oct 8, 2021 · 3 comments
Labels
type: enhancement It's working, but needs polishing

Comments

@mtreinish
Copy link
Member

mtreinish commented Oct 8, 2021

What is the expected enhancement?

Right now we have 4 optimization levels 0-3 that right now are split like:

Optimization Level 0:
No optimization passes run, just trivial layout -> stochastic swap -> basis translator

Optimization Level 1:
Trivial Layout/Dense layout -> stochastic swap -> basis translator -> optimization loop (optimize 1q gates and cx cancellation)

Optimization Level 2:
CSPLayout/Trivial Layout/Dense layout -> stochastic swap -> basis translator -> optimization loop (optimize 1q gates and commutative cancellation)

Optimization Level 3:
CSPLayout/Trivial Layout/Dense layout -> stochastic swap -> basis translator -> optimization loop (2q block collection and synthesis, optimize 1q gates and commutative cancellation)

Also passes that are shared between levels and have configurable numbers of trials use more at higher optimization levels.

However with recent performance improvements we've made in Qiskit the past couple of years we have some time budget to improve the quality of the circuits we output at level 1 and add more passes to the higher optimization levels.

This is related to #7016 where some simple hand optimizations were not being performed at the default level 1. I think we need to characterize the runtime performance of the different passes and compare the tradeoff in utility they provide and once we have a better sense for this in data we can make informed decision.

@mtreinish mtreinish added the type: enhancement It's working, but needs polishing label Oct 8, 2021
@mtreinish mtreinish changed the title Rework preset pass mangers Rework preset pass mangers levels Oct 8, 2021
@mtreinish
Copy link
Member Author

The rough idea I had was basically to shift everything >1 down one level so that level 1's optimization loop has commutative cancellation, level 2 has the 2q collection and synthesis, and level 3 we add more optimization passes to like template optimization (would require performance work prior to adding). But this would all need to be measured so we can make informed decisions instead of picking blindly.

@kdk kdk added this to the 0.19 milestone Oct 26, 2021
@kdk
Copy link
Member

kdk commented Oct 26, 2021

For 0.19, introducing sabre as the default {layout,routing}_method (following #7036) maybe at higher optimization_levels seems a place to start.

@nonhermitian
Copy link
Contributor

The default should be O3 with Sabre layout and routing. Otherwise users get sub-optimal performance across most circuits, especially when compared to other compilers. This shows up again and again in benchmarks from others.

mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Nov 1, 2021
This commit switches the default routing and layout method for
optimization level 3 to use SabreSwap and Sabre layout passes. The
quality of results is typically better with sabre than the default
stochastic swap and dense layout we're using now. For optimization
level 3 where we try to produce the best quality result and runtime
is of secondary concern using sabre makes the most sense (especially
after Qiskit#7036 which improves the runtime performance). Also for
optimization level 3 currently sabre is typically faster because we
increase the number of trials for stochastic swap (which is generally
significantly faster) which slows it down as it's doing more work.
This should improve the quality and speed of the results in general
when running with optimization level 3. In the future we can do more
work to improve the runtime performance of the sabre passes and
hopefully make it fast enough to use for all the optimization levels
which have more constraints on the run time performance than level 3.

Related to Qiskit#7112 and Qiskit#7200
@mtreinish mtreinish modified the milestones: 0.19, 0.20 Nov 2, 2021
mergify bot added a commit that referenced this issue Nov 20, 2021
* Switch default routing/layout method to sabre for opt level 3

This commit switches the default routing and layout method for
optimization level 3 to use SabreSwap and Sabre layout passes. The
quality of results is typically better with sabre than the default
stochastic swap and dense layout we're using now. For optimization
level 3 where we try to produce the best quality result and runtime
is of secondary concern using sabre makes the most sense (especially
after #7036 which improves the runtime performance). Also for
optimization level 3 currently sabre is typically faster because we
increase the number of trials for stochastic swap (which is generally
significantly faster) which slows it down as it's doing more work.
This should improve the quality and speed of the results in general
when running with optimization level 3. In the future we can do more
work to improve the runtime performance of the sabre passes and
hopefully make it fast enough to use for all the optimization levels
which have more constraints on the run time performance than level 3.

Related to #7112 and #7200

* Clarify punctuation in release note

Co-authored-by: Jake Lishman <jake@binhbar.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
@mtreinish mtreinish modified the milestones: 0.20, 0.21 Mar 26, 2022
@kdk kdk modified the milestones: 0.21, 0.22 Jun 14, 2022
@mtreinish mtreinish modified the milestones: 0.22, 0.23.0 Sep 19, 2022
@mtreinish mtreinish modified the milestones: 0.23.0, 0.24.0 Jan 9, 2023
@kdk kdk removed this from the 0.24.0 milestone Apr 5, 2023
mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Nov 7, 2023
This commit updates the default optimization stage plugin to use the
InverseCancellation pass instead of CXCancellation for optimization
level 1. The CXCancellation pass was hard coded to only cancel runs of
CX gates on the same qubits. This was fine when CX is the target, but
for other targets which aren't using CX the pass had no value. An
alternative, more general, inverse cancellation pass was added in Qiskit#6855
that enables defining arbitrary inverse cancellation rules and
simplifying a dag based on it. This commit updates the default
optimization plugin at optimization level 1 to use this with some common
inverse rules for 2q gates from the standard gate library.

Closes: Qiskit#6576
Closes: Qiskit#7016
Related-to: Qiskit#7112
mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Nov 7, 2023
This commit updates the default optimization stage plugin to use the
InverseCancellation pass instead of CXCancellation for optimization
level 1. The CXCancellation pass was hard coded to only cancel runs of
CX gates on the same qubits. This was fine when CX is the target, but
for other targets which aren't using CX the pass had no value. An
alternative, more general, inverse cancellation pass was added in Qiskit#6855
that enables defining arbitrary inverse cancellation rules and
simplifying a dag based on it. This commit updates the default
optimization plugin at optimization level 1 to use this with some common
inverse rules for 2q gates from the standard gate library.

Closes: Qiskit#6576
Closes: Qiskit#7016
Related-to: Qiskit#7112
github-merge-queue bot pushed a commit that referenced this issue Nov 8, 2023
)

* Use InverseCancellation in opt level 1 instead of CXCancellation

This commit updates the default optimization stage plugin to use the
InverseCancellation pass instead of CXCancellation for optimization
level 1. The CXCancellation pass was hard coded to only cancel runs of
CX gates on the same qubits. This was fine when CX is the target, but
for other targets which aren't using CX the pass had no value. An
alternative, more general, inverse cancellation pass was added in #6855
that enables defining arbitrary inverse cancellation rules and
simplifying a dag based on it. This commit updates the default
optimization plugin at optimization level 1 to use this with some common
inverse rules for 2q gates from the standard gate library.

Closes: #6576
Closes: #7016
Related-to: #7112

* Add sx sx dagger inverse pair to pass
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement It's working, but needs polishing
Projects
None yet
Development

No branches or pull requests

3 participants