Skip to content
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

Closed
WrathfulSpatula opened this issue Aug 21, 2021 · 4 comments
Closed

Restore an improved QFusion layer #871

WrathfulSpatula opened this issue Aug 21, 2021 · 4 comments
Assignees

Comments

@WrathfulSpatula
Copy link
Collaborator

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
Copy link
Collaborator Author

WrathfulSpatula commented Aug 22, 2021

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

WrathfulSpatula commented Aug 28, 2021

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
Copy link
Collaborator Author

This was completed, in the QMaskFusion layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant