Closed WrathfulSpatula closed 3 years ago
I think that the old QFusion
layer (in addition to being bugged) might have failed to take advantage of many of our recently realized implementations of commutation rules, such as between controls, phase gates, and "inversion" gates, (to make "anti-controls,") and we might rather lift large parts of special case QUnit
and QStabilizerHybrid
gate fusion up into this layer, if it actually happens to serve performance and abstraction.
I've found a recent paper on "Faster Schrödinger-style simulation of quantum circuits," which applies to us: https://arxiv.org/abs/2008.00216
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 QFusion
layer, or QUnit
, should hopefully be able to cache single qubit gates like X
, to apply them in fewer traversals, using this method.
I now have XMask()
, YMask()
, and ZMask()
gates. Next, I'll build a separate fusion layer to coalesce and commute Pauli gates into a smaller number of applications of these methods.
This was completed, in the QMaskFusion
layer.
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
.)