-
Notifications
You must be signed in to change notification settings - Fork 42
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
Direct Support to probabilities, expectation values and variances in PL-Lightning #185
Conversation
Hello. You may have forgotten to update the changelog!
|
Codecov Report
@@ Coverage Diff @@
## master #185 +/- ##
=======================================
Coverage 99.64% 99.64%
=======================================
Files 4 4
Lines 278 278
=======================================
Hits 277 277
Misses 1 1 Continue to review full report at Codecov.
|
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.
Thanks for putting this together @AmintorDusko
I have some comments and questions:
I will work on every request and suggestion. Thanks for your feedback @mlxd . |
Please let me know your thoughts. |
Hi @mlxd. Following our discussion, I updated the probabilities calculations. |
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.
Thanks for this @AmintorDusko.
I have left some comments and queries.
template <typename T> | ||
auto transpose_state_tensor( | ||
const std::vector<T> &tensor, | ||
const std::vector<size_t> &new_axes) | ||
-> std::vector<T> { | ||
std::vector<T> transposed_tensor(tensor.size()); | ||
for (size_t ind=0; ind<tensor.size(); ind++){ | ||
transposed_tensor[ind]=tensor[transposed_state_index(ind, new_axes)]; | ||
} | ||
return transposed_tensor; | ||
} |
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.
I worry this may be slow for large data sets. Can you run some numbers on this and see how it performs for various numbers of qubits.
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.
Yes. Sure.
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.
I explored some alternative strategies for this transposition, and at least for now, this seems to be the more efficient. In the other hand, It doesn't seem to be too slow.
I checked the performance for 100 runs, up to 22 qubits.
I applied the transpose_state_tensor
function to vectors with the size of the equivalent state vector (or tensor). This shows exactly the information we are interested in. For 22 qubits, we have a vector with 8,388,608 elements, and the mean time is 0.89 seconds.
A loop like that, with no data dependency, is quite the low-hanging fruit for openMP parallelisation, but for the sizes I'm presenting here quite of an overkill. If you think we should proceed with some parallelisation strategy, I think we could impose a threshold based in the number of qubits.
The code was compiled in GCC 11 with the -Ofast flag.
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.
Thanks Amintor. I do think we should ensure this is fast for <=30 qubits (for large node usage). We can add parallelism as a next pass though.
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.
Hi @mlxd ,
I extended the benchmark to 26 qubits (memory is limiting this range).
I optimised the code to determine the transposed index, and the function to transpose the tensor, accordingly.
The best method so far is still based in transpose the tensor after the calculation of the probabilities.
Anyway, in this new approach for the tensor transposition, I could observe a huge increase in speed, for larger number of qubits. I'm comparing the two methods here:
I also plotted the ration between the two times:
For 26 qubits, the previous algorithm is taking 18.4 seconds, while the new one is taking 2.3 seconds. The new code is approximately 8 times faster. This qubit state vector has 67,108,864 elements. I'm performing calculation with double precision, and compiling with the -Ofast flag.
We can observe an outlier in 12 qubits, where the previous algorithm seems to outperform the new one. The ration here is 0.85, and this may be because of the number of samples (100). Also, we are talking about small number and this could be strongly affected by fluctuations.
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.
In other run, the 12 qubits performed better in the new algorithm. I think it is reasonable to assume that the measure of times in this fast cases is specially prone to fluctuations. It seems that starting in 20 qubits would be a good choice.
Hi @mlxd. Let me know what you think. |
Thanks Amintor. I think I am happy to merge this in as the initial pass. We can add the Python bindings in a follow up PR. |
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.
After the change listed here, I think this is good to go.
// transposed_tensor[ind] = tensor[transposed_state_index(ind, | ||
// new_axes)]; |
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.
// transposed_tensor[ind] = tensor[transposed_state_index(ind, | |
// new_axes)]; |
Makes sense. Thanks! |
Context:
Pennylane Lightning doesn't offer direct support for the calculation of probabilities, expectation values and variances.
Description of the Change:
This PR introduces a C++ class template
Measures
that implements such calculations.Calculations can be performed in terms of the already defined gates, or with any operator provided as a matrix.
Benefits:
A direct implementation in C++ expands the optimization options, and this class allows to perform such calculations for any operator provided in matrix form.
Possible Drawbacks:
I'm not aware of.
Related GitHub Issues: