-
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
Fix unnecessary serialisation of PassManager
in serial contexts
#12410
Conversation
This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends.
One or more of the the following people are requested to review this:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make this eligible for backport I was thinking that we leave should_run_in_parallel
as an internal function for now. I agree having it in the public api makes sense longer term, but if we wanted to include this fix in 1.1.x we don't need to expose it in this PR.
Pull Request Test Coverage Report for Build 9098821180Details
💛 - Coveralls |
This makes the patch series safe for backport to 1.1.
…2410) * Fix unnecessary serialisation of `PassManager` in serial contexts This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends. * Remove new function from public API This makes the patch series safe for backport to 1.1. (cherry picked from commit b12e9ec)
…2410) (#12413) * Fix unnecessary serialisation of `PassManager` in serial contexts This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends. * Remove new function from public API This makes the patch series safe for backport to 1.1. (cherry picked from commit b12e9ec) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
Do you think it makes sense to backport this to stable/0.46? |
…skit#12410) * Fix unnecessary serialisation of `PassManager` in serial contexts This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends. * Remove new function from public API This makes the patch series safe for backport to 1.1.
@Mergifyio backport stable/0.46 |
✅ Backports have been created
|
…2410) * Fix unnecessary serialisation of `PassManager` in serial contexts This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends. * Remove new function from public API This makes the patch series safe for backport to 1.1. (cherry picked from commit b12e9ec) # Conflicts: # qiskit/utils/__init__.py # qiskit/utils/parallel.py
…ckport #12410) (#12500) * Fix unnecessary serialisation of `PassManager` in serial contexts (#12410) * Fix unnecessary serialisation of `PassManager` in serial contexts This exposes the interal decision in `parallel_map` of whether to actually run in serial or not. If not, there's no need for `PassManager` to side-car its `dill` serialisation onto the side of the IPC (we use `dill` because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends. * Remove new function from public API This makes the patch series safe for backport to 1.1. (cherry picked from commit b12e9ec) # Conflicts: # qiskit/utils/__init__.py # qiskit/utils/parallel.py * solve conflicts * passmanager does not know the cpu_count --------- Co-authored-by: Jake Lishman <jake.lishman@ibm.com> Co-authored-by: Luciano Bello <bel@zurich.ibm.com>
Summary
This exposes the interal decision in
parallel_map
of whether to actually run in serial or not. If not, there's no need forPassManager
to side-car itsdill
serialisation onto the side of the IPC (we usedill
because we need to pickle lambdas), which can be an unfortunately huge cost for certain IBM pulse-enabled backends.Details and comments
@sbrandhsn: as the release manager for 1.1.0, it's up to you whether you want to accept this PR in this form for 1.1.0, or defer to 1.1.1 (you can tag the milestone appropriately). I could also suppress exporting
should_run_in_parallel
into the public namespace if you're not on board with a new public feature this late into the release cycle.