-
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
Rework preset pass mangers levels #7112
Comments
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. |
For 0.19, introducing |
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. |
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
* 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>
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
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
) * 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
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.
The text was updated successfully, but these errors were encountered: