Make Optimize1qGatesDecomposition multithreaded#15567
Draft
mtreinish wants to merge 7 commits intoQiskit:mainfrom
Draft
Make Optimize1qGatesDecomposition multithreaded#15567mtreinish wants to merge 7 commits intoQiskit:mainfrom
mtreinish wants to merge 7 commits intoQiskit:mainfrom
Conversation
This commit switches to make optimize1qgatesdecomposition a parallel transpiler pass. After we collect the 1q runs in the dag the step of computing the unitary matrix for each run and synthesizing it has no data dependency and can be run in parallel without issue. However updating the dag with synthesis results is still serial so there are limits to how much can be parallelized here. Additionally, in the previous serial version the target euler bases to try were computed eagerly the first time a qubit with a run was encountered. This would force a data dependency between the threads which either require locking or precomputing the target bases, which is what this commit does. This means that instantiating the pass object is slower and we're potentially doing more work up front than is strictly necessary. However this does have the advantage of being amortizable over multiple executions of the pass which before it was not. A quick experiment was run to determine that when there are roughly 100,000 runs to process (all runs of 20 gates) is the crossover point for the parallel version vs the serial version. This was used to set a run count that is used to select between a serial and parallel version of the algorithm.
mtreinish
added
performance
Rust
This commit reworks the change in logic from the previous commit to no longer pre-compute the euler basis set for each qubit regardless of whether it's used or not. The state object used to store the basis gates and euler basis sets is kept as this enables more efficient patterns on multiple runs of the pass. Now the state uses OnceLock to enable each thread to lazily populate the state on the first run of a qubit. This saves the construction time overhead if qubits never have runs but keeps the advantages of reused state.
In earlier commits a crossover value of 100,000 runs was used to switch between serial and parallel runs. This was based on a scaling experiment that indicated this was about when parallel became faster. But further testing is showing this not to be as clear cut. Until we make a determination around that and finalize the implementation this commit leaves the value there as a TODO and the pass is always multithreaded unless in a multiprocessing context.
In the earlier commit moving to use lazy initialization this wasn't tested in a parallel context previously and the method of initialization wasn't atomic which led to a race condition between threads trying to populate runs on the same qubit concurrently. This commit fixes this by adjusting the OnceLock usage to properly use the API for initialization to fix this issue.
Pull Request Test Coverage Report for Build 21009131987Warning: 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 |
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
3 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.
Summary
This commit switches to make optimize1qgatesdecomposition a parallel transpiler pass. After we collect the 1q runs in the dag the step of computing the unitary matrix for each run and synthesizing it has no data dependency and can be run in parallel without issue. However updating the dag with synthesis results is still serial so there are limits to how much can be parallelized here. Additionally, in the previous serial version the target euler bases to try were computed eagerly the first time a qubit with a run was encountered. This would force a data dependency between the threads which either require locking or precomputing the target bases, which is what this commit does. This means that instantiating the pass object is slower and we're potentially doing more work up front than is strictly necessary. However this does have the advantage of being amortizable over multiple executions of the pass which before it was not.
A quick experiment was run to determine that when there are roughly 100,000 runs to process (all runs of 20 gates) is the crossover point for the parallel version vs the serial version. This was used to set a run count that is used to select between a serial and parallel version of the algorithm.
Details and comments
TODO: