Open ltalirz opened 2 years ago
If it's alright with you, I think it might make sense to transfer this issue to the qsharp-runtime repo, since it looks like your issue report concerns the trace simulator / resources estimator rather than its Python or Jupyter protocol wrappers.
In any case, it jumps out at me that the operation being estimated in your screenshot uses 42M CNOT calls, 24M single-qubit Clifford calls, and 9M single-qubit rotations; given that, 3 minutes and 21 seconds is still likely faster than running on the full-state simulator, given that corresponds to a gate time on the order of 1µs or so for a nine-qubit register.
I'm also a bit surprised as to the relative breakdown between CPU time and wall time; @DmitryVasilevsky, would you have any ideas as to the root cause there? Thanks!
Thanks a lot for the feedback @cgranade! Please feel free to transfer the issue as you deem appropriate. I opened it here since I thought one might fix it just by choosing a less expensive simulation for the demo notebook - but if there is indeed an underlying issue, I guess it's good to transfer.
As for the timings I cannot comment beyond the fact that the subsequent calculation in the notebook ends up being faster
All calculations in the notebook run relatively quickly, as one would expect for a demo. Except one: The resource estimation for the RPE calculation takes ~3 minutes (running the actual algorithm later actually only takes 45s)
Without a dedicated comment, a naive user (like me) might expect the resource estimation to be fast (I would certainly have expected it to be faster than running the algorithm) and thus start thinking that something is not working properly.
Is there a way to speed this step up? If not, it might be useful to add a comment here to the effect that one may need to wait several minutes.