Parallelize probs with OpenMP
#800
Merged
Conversation
This file contains 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
…ements/MeasurementKernels.hpp Co-authored-by: Amintor Dusko <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #800 +/- ##
==========================================
- Coverage 98.64% 92.36% -6.29%
==========================================
Files 114 73 -41
Lines 17653 11167 -6486
==========================================
- Hits 17414 10314 -7100
- Misses 239 853 +614 ☔ View full report in Codecov by Sentry. |
|
I think that it would be nice to add a scaling efficiency plot. What do you think @vincentmr ? |
pennylane_lightning/core/src/simulators/lightning_qubit/measurements/MeasurementsLQubit.hpp
Show resolved
Hide resolved
LuisAlfredoNu
approved these changes
Jul 16, 2024
AmintorDusko
approved these changes
Jul 16, 2024
5 tasks
vincentmr
added a commit
that referenced
this pull request
Jul 24, 2024
### Before submitting
Please complete the following checklist when submitting a PR:
- [x] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to
the
[`tests`](../tests) directory!
- [x] All new functions and code must be clearly commented and
documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running `make docs`.
- [x] Ensure that the test suite passes, by running `make test`.
- [x] Add a new entry to the `.github/CHANGELOG.md` file, summarizing
the
change, and including a link back to the PR.
- [x] Ensure that code is properly formatted by running `make format`.
When all the above are checked, delete everything above the dashed
line and fill in the pull request template.
------------------------------------------------------------------------------------------------------------
**Context:**
`sample` call `generate_samples` which computes the full probabilities
and uses the alias method to generate samples for all wires. This is
wasteful whenever samples are required only for a subset of all wires.
**Description of the Change:**
Move alias method logic to the `discrete_random_variable` class.
**Benefits:**
Compute minimal probs and samples.
We benchmark the current changes against `master`, which already
benefits from some good speed-ups introduce in #795 and #800 .
We use ISAIC's AMD EPYC-Milan Processor using a single core/thread. The
times are obtained using at least 5 experiments and running for at least
250 milliseconds. We begin comparing `master`'s
`generate_samples(num_samples)` with ours `generate_samples({0},
num_samples)`. For 4-12 qubits, overheads dominate the calculation (the
absolute times range from 6 microseconds to 18 milliseconds, which is
not a lot. Already at 12 qubits however, a trend appears where our
implementation is significantly faster. This is to be expected for two
reason: `probs(wires)` itself is faster than `probs()` (for enough
qubits) and `sample(wires)` starts also requiring significantly less
work than `sample()`.
Next we turn to comparing `master`'s `generate_samples(num_samples)`
with ours `generate_samples({0..num_qubits/2}, num_samples)`. The
situation there is similar, with speed-ups close to 1 for the smaller
qubit counts and (sometimes) beyond 20x for qubit counts above 20.
Finally we compare `master`'s `generate_samples(num_samples)` with ours
`generate_samples({0..num_qubits-1}, num_samples)` (i.e. computing
samples on all wires). We expect similar performance since the main
difference comes from the caching mechanism in `master`'s discrete
random variable generator. The data suggests caching samples is
counter-productive compared with calculating the sample values on the
fly.
Turning OMP ON, using 16 threads and comparing `master`'s
`generate_samples(num_samples)` with ours `generate_samples({0},
num_samples)` we get good speed-ups above 12 qubits. Below that the
overhead of spawning threads isn't repaid, but absolute times remain
low.
**Possible Drawbacks:**
**Related GitHub Issues:**
[sc-65127]
---------
Co-authored-by: ringo-but-quantum <[email protected]>
Co-authored-by: Ali Asadi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Before submitting
Please complete the following checklist when submitting a PR:
All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
testsdirectory!All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running
make docs.Ensure that the test suite passes, by running
make test.Add a new entry to the
.github/CHANGELOG.mdfile, summarizing thechange, and including a link back to the PR.
Ensure that code is properly formatted by running
make format.When all the above are checked, delete everything above the dashed
line and fill in the pull request template.
Context:
probsis central in circuit simulation measurements.Description of the Change:
Parallelize
probsloops using OpenMP.Benefits:
Faster execution with several threads.
The following benchmarks are performed on ISAIC's AMD EPYC-Milan Processor using a several core/threads. The times are obtained averaging the computation of
probs(target)5 times for various number of targets. We use the last release implementation as a reference. Since #795 brings some speed-ups even for a single thread, this is why we observe speed-ups > number of threads.Another view on the data is the strong scaling efficiency. It is almost perfect for 2-4 threads, fairly good for 8 threads and diminishes significantly for 16 threads.
Possible Drawbacks:
Related GitHub Issues: