Quantum Savory
-
|
I noticed that there are differences in the runtime of Maybe this is a feature not a bug, such that the user can decide if the whole state is always considered in calculation; but since the register holds physically the same state and it makes a large difference performance wise, it would be good for the user to get e.g., a warning that not only the specific subspace is used during calculation but the whole initialized Hilbert space. Expected behavior I would expect the below example to either run with the same execution time or trigger a warning in case 1. Minimal Reproducible Example 👇 using QuantumSavory
n = 15
# Case 1: register initialized with X1 product state
reg = Register(n, QuantumOpticsRepr())
initialize!(reg[1:n], reduce(⊗, fill(X1,n)))
timed_compile = @elapsed apply!((reg[1]), H)
timed_compute = @elapsed apply!((reg[1]), H)
@info timed_compile, timed_compute
# Case 2: register initialized with X1 individual states
reg = Register(n, QuantumOpticsRepr())
for i in 1:n initialize!(reg[i], X1) end
timed_compile = @elapsed apply!(reg[1], H)
timed_compute = @elapsed apply!(reg[1], H)
@info timed_compile, timed_compute[ Info: (48.7393675, 46.076166333)
[ Info: (0.072435042, 0.000156375) |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 9 replies
-
|
I am converting this to a discussion as it is an interesting question, but it is not a bug, rather an expected behavior. If you initialize To be fair, in your particular case we are not given a state vector, rather we are given a symbolic tensor product. So in principle it is possible to special-case the tensor product. I will look into this... I guess I should not have converted this to a discussion :D But the bigger point is, this type of "detect that a big state is separable" are generally expensive and unreliable and code should be structured to not expect them to exist. |
Beta Was this translation helpful? Give feedback.
-
|
I thought so! Intuitively it makes sense that it works this way -- the only reason I fell into this, was because I needed to do some single qubit operations first to all qubits sitting in a register before entangling them. Not knowing the standard way to initialize, I used inspiration from some of the examples in qs, where initialization was done with the complete product state, so I just defaulted to that. Maybe it would rather be a good add to the documentation of |
Beta Was this translation helpful? Give feedback.
-
|
Extra documentation is always appreciated! Do not hesitate to submit a PR -- discussion on the topic would be useful even with the performance improvements that were pushed recently. |
Beta Was this translation helpful? Give feedback.
-
|
Here is an attempt to do a special case for tensor products: Here is the result on my computer for your benchmarks: |
Beta Was this translation helpful? Give feedback.
-
|
ah ok wow nice! |
Beta Was this translation helpful? Give feedback.
-
|
It is now merged. Let me know if you still have this slowdown |
Beta Was this translation helpful? Give feedback.
-
|
I will check later today, but could you:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
oh, according to this you do not have the dev version of the library. Maybe at some point you have done |
Beta Was this translation helpful? Give feedback.
-
|
after you do that and run |
Beta Was this translation helpful? Give feedback.
-
|
Aah yes, that was it thanks! 🥳 |
Beta Was this translation helpful? Give feedback.
I am converting this to a discussion as it is an interesting question, but it is not a bug, rather an expected behavior.
If you initialize
nslots to an entangled multi-qubit state, behind the scenes we need to store2^ncomplex numbers. If the state is not entangled but completely separable, it isn*2complex numbers. But if you are given an arbitrary state vector, it is a very expensive operation to check whether the state is entangled or not, so we can not automatically go to the non-entangled storage format.To be fair, in your particular case we are not given a state vector, rather we are given a symbolic tensor product. So in principle it is possible to special-case the tensor produ…