unitaryfund / qrack

Comprehensive, GPU accelerated framework for developing universal virtual quantum processors
https://qrack.readthedocs.io/en/latest/
GNU Lesser General Public License v3.0
176 stars 38 forks source link

Restore an improved `QFusion` layer #871

Closed WrathfulSpatula closed 3 years ago

WrathfulSpatula commented 3 years ago

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 want QFusion as a "layer" over QUnit, rather than under, for these purposes, despite earlier applications of QFusion.)

WrathfulSpatula commented 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.

WrathfulSpatula commented 3 years ago

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.

WrathfulSpatula commented 3 years ago

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.

WrathfulSpatula commented 3 years ago

This was completed, in the QMaskFusion layer.