-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
Restore an improved QFusion
layer
#871
Comments
I think that the old |
I've found a recent paper on "Faster Schrödinger-style simulation of quantum circuits," which applies to us: Among other optimizations, this paper suggests not padding gate operators with identity operators. That is, if we're applying 10 Pauli X gates on different bits, for example, do them in one state vector traversal. We cut a gate optimization like this in the distant past, with X gates in parallel across a contiguous set of qubits, because we didn't effectively leverage it. Instead, we could have a multiple Pauli X gate on an arbitrary list of qubits that performs every X gate in a single traversal. The new |
I now have |
This was completed, in the |
Over in my OpenRelativity fork, with its Qrack plugin, I'm in the early stages of developing a "chip-like" benchmark quantum computer simulation, (in a relativistic background,) where gates are enacted in an approximately continuous way over a fixed time interval, effectively via finite difference simulation, with a finite difference time step smaller than the time interval to enact a gate. This is entirely speculative, "for fun," but I'm making a guess, that it could be "meaningful" (if not uniquely "physical," still semi-arbitrary) to approximate the continuous time-evolution, of a gate that takes finite time, as a continuously composed power of the end-result gate desired, from 0 to 1 as the power. This use case might be more general than my "toy," though.
This kind of simulation would benefit from simple "gate fusion." like our deprecated
QFusion
layer. It's probably worth reviving, debugging, and improving that layer, at least for special case application, (like my case in OpenRelativity, now).To first consideration, I don't think a
QFusion
-type layer would really afford us performance improvement without the ability (at least in some semi-general cases) to check Z basis probability without causing the gate fusion buffers to flush. Turns out, for single qubit gate fusion buffers directly over a stabilizer layer, we were able to make probability checks without flushing these kinds of buffers, with total generality. Perhaps, we can extend that concept for this case, or approach it a different way. (I'm guessing that we would typically wantQFusion
as a "layer" overQUnit
, rather than under, for these purposes, despite earlier applications ofQFusion
.)The text was updated successfully, but these errors were encountered: