-
Notifications
You must be signed in to change notification settings - Fork 163
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
Implement SimulatesIntermediateState Cirq interface #101
Comments
As I understand it, a core part of qsim behavior is fusing gates along the time-axis into independent chunks. Simulating step by step in a single execution would require modifying that core behavior, which is likely a significant amount of effort. The alternative is to run each timestep as a separate circuit in sequence, which I suspect would impact the overall performance of the simulator. @sergeisakov, could you offer your thoughts on this? |
In principle, this can be implemented. One doesn't need to modify qsim as it can run gates step by step without fusion. As @95-martin-orion pointed out, this will impact the overall performance of the simulator. The effort would be to implement the interface between Cirq and qsim. |
Has there been any development on this? I suspect it will enable big savings for things like XEB where we have one big circuit that we want to know the wavefunction at various steps |
on an XEB workload:
|
Since we only need the results after each "cycle" (and indeed, only for certain cycle settings) it could be worthwhile to
|
I guess there's been no development on this. The core qsim library supports boundaries and can return the wavefunction at various steps. One sample C++ application (qsim_amplitudes.cc) saves intermediate results. The qsimcirq interface doesn't support that. |
I think it would be possible to construct this with a combination of
There are a few key flaws with this format, most notably that qsim would need to store all intermediate states since we have no way of doing "streaming output" from a qsim run. Separately, I don't think we support returning results from Unfortunately, I don't have a lot of bandwidth to look at this right now. @mpharrigan, if you're interested in taking a stab at it I'd be happy to point you to the relevant parts of the code. |
This PR speeds up the classical simulation of XEB circuits, which is important because it is in the hot loop for optimization. Single threaded: old: 0.72s new: 3.72s speedup: 5x multiprocessing pool on my laptop: old: 1.42s new: 0.21s speedup: 7x - Instead of using a loosely schema'd dictionary for passing arguments to the simulation helper function, use a private dataclass - The helper function has been promoted to a helper closure class. This is so 1) it can work under multiprocessing while 2) storing its `self.Simulator` to use. This enables a user-provided simulator object. Anything that follows the `SimulatesIntermediateState` interface. Currently, this is just `cirq.Simulator` but there's an outstanding request to use qsim in this way. quantumlib/qsim#101. Please see the linked issue for potential speedups. Right now, `cirq.Simulator` with intermediate capabilities is faster than qsim operated naively
Two updates on this: Update 1 Update 2
which achieves the desired result and allows Python-side management of the resulting state copies. |
This interface allows access to intermediate states as the circuit is simulated moment-by-moment. See https://github.com/quantumlib/Cirq/blob/720ea341b0082dc0cbbfb0142c161f01d8edca3e/cirq/sim/simulator.py#L258.
How difficult would this be?
The text was updated successfully, but these errors were encountered: