Refactor QubitWaveFunction, add support for Numpy array backed dense representation #370
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.
When running
simulate
to get the output wavefunction of a circuit, currently the conversion from the array that the backend returns to the dictionary format that Tequila uses can be a bottleneck.This pull request fixes this by refactoring the
QubitWaveFunction
class and allowing it to either use a dictionary for sparse wavefunctions, or a Numpy array for dense wavefunctions.To see the performance improvement, consider the code from my previous pull request, but increase the number of qubits to 22:
Code
On the current
devel
branch, this takes around 10 seconds for only the QFT, and around 2.4 seconds for the QFT combined with the inverse. With this pull request, this is reduced to around 0.95s / 1.85s. Not only is it faster, but the larger circuit is now slower, unlike before where the larger circuit was faster because the result was a sparse wavefunction. The time spent in the Qulacsupdate_quantum_state
method is around 0.7s / 1.4s, so now the simulation actually makes up the majority of the runtime.In theory, both sparse and dense representations should be functionally equivalent, and the only difference should be a space-time tradeoff.
Most of the time, the sparse representation is used by default to preserve the previous behaviour.
The dense representation is used when the wavefunction is constructed from an array, or when it is chosen explicitly.
I also made various other changes to the wavefunction API.