Consider merging Compilers and Simulators Top-level Tasks

[nathanshammah]

Most compilers are also simulators and viceversa, simulators contain compilers to increase their efficiency and optimize against certain metrics. I understand that by compilers we also mean compilers that may be thought to compile on quantum hardware only, but at some level they contain a quantum circuit simulation / representation.

As a user, I am sometimes confounded of whether a compiler should be a simulator or vice versa. For example, qutip-qip is a quantum circuit simulator (with pulse-level simulation) that contains a compiler.

[WrathfulSpatula]

@crazy4pi314 seemed to indicate a similar reasoning to me at one point, that these two are much the same. However, as lead developer of vm6502q/qrack, I am not convinced. Qrack is specifically not a compiler, for example. It has no capability to compile for any back end except for Qrack simulator types, and I would conscientiously object to classifying what the library does for even these back ends as "compilation."

For one thing, much of the optimization in Qrack is based on properties of the in-flight simulation state that don't have equivalency to native hardware compilation techniques. For example, the "Schmidt decomposition" techniques of QUnit introspect for "separability" of sub-systems of qubits; my understanding is that "separability" makes basically no difference to (noiseless, scalable) native hardware compilation in the ideal, while it makes a huge difference to efficient simulation. (IBM might be starting to use techniques like "entanglement forging" meant to leverage a concept like "separability" for improving hybrid system capabilities, but Qrack simply doesn't do this, yet.) Similarly, QPager optimizes around the assumptions that "pages" of "sub-simulators" will be split equally on permutation amplitude count, with denormalized "page" probability; there is no (Intel-QS-like) equivalent of concept of a denormalized "page" of permutation amplitudes in a native quantum computer, though, where time evolution of state is unitary up to noise and measurement. (We could add to this list, like with CPU/GPU switch-off thresholds, which just don't have a native quantum hardware equivalent, etc..)

(I'm writing a long response to this, because I consider it a semi-common misconception, as author of Qrack. Bottom line is, my simulator doesn't fit in the "Compilation" bucket, as best I can figure.)

[crazy4pi314]

@WrathfulSpatula I don't think I have ever expressed anything like this :P

I think it is fair to keep the buckets as is, and things can live in more than one if the have the functionality?

[WrathfulSpatula]

@crazy4pi314 Sorry, I imagined it. Never mind.

Notwithstanding, my argument against the issue remains as I wrote it above. I think there might be a quasi-common belief or intuition that simulation is basically a special case of general quantum computer compilation, but I don't think it actually is, as a simulator developer.

[crazy4pi314]

I agree with you @WrathfulSpatula, and would only suggest that tools that can do both (like QDK) should show up on both lists.

[WrathfulSpatula]

QDK compilation vs. QDK runtime simulation could be entered under the respective topics, by design. This would be on a per-task basis, and both types of task could occur in the same submission. We'd want to combine the top-level task categories only if the results were topically common; I don't think they are. However, the issue ticket can serve to remind us to look at whether the two are distinct or common.

[WrathfulSpatula]

I think we can close this. Like I said in my last comment, we can differentiate between compilation vs. runtime, but allowing multiple parent tasks isn't in the design of the task hierarchy, and I don't consider this issue (or anything else we've come across) to be compelling enough to change that aspect of the fundamental design of the hierarchy.