-
Notifications
You must be signed in to change notification settings - Fork 35
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add
sample(wires)
support in LightningQubit (#809)
### 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()`. ![speedup_vs_nthreads_1w](https://github.com/user-attachments/assets/472748e9-d812-489c-a00f-2b2b74c7e682) 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. ![speedup_vs_nthreads_hfw](https://github.com/user-attachments/assets/f39e3ccd-8051-4a57-a857-9cd13f547865) 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. ![speedup_vs_nthreads_fullw](https://github.com/user-attachments/assets/2c70ed21-2236-479e-be3d-6017b42fdc5e) 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. ![speedup_vs_omp16_1w](https://github.com/user-attachments/assets/e3e90a55-399f-4a5b-b90e-7059a0486228) **Possible Drawbacks:** **Related GitHub Issues:** [sc-65127] --------- Co-authored-by: ringo-but-quantum <github-ringo-but-quantum@xanadu.ai> Co-authored-by: Ali Asadi <10773383+maliasadi@users.noreply.github.com>
- Loading branch information
1 parent
9a83ff4
commit de7beb7
Showing
9 changed files
with
180 additions
and
148 deletions.
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,4 +16,4 @@ | |
Version number (major.minor.patch[-label]) | ||
""" | ||
|
||
__version__ = "0.38.0-dev12" | ||
__version__ = "0.38.0-dev13" |
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
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
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
Oops, something went wrong.