Classical Control: Loops/Branches/Conditions

[balopat]

Problem: Cirq currently only supports a single unrolled circuit. In Feedforward above a simple example of a flow control primitive, a simple conditional is considered. This feature is to expand the set of flow control primitives. Examples of these primitives could be count-controlled loops (for loops), condition-controlled loops (while blocks), collection-controlled loops (for loops for collections), early exit from loops, skipping from loops, case statements. In addition to the flow controls themselves, specification of what can be done with the data that is consumed and produced by these flow controls needs to be specified.

Depends on feature: Classical data (#3231)

Rough requirements:

• Allow users to use flow control statements in their programs
• Specify how execution unrolls.
• Support serialization of the specification of flow control.
• Fit in with the specification of data in the Classical Data feature

[daxfohl]

Could we turn this inside out? I would think the flow control could remain in Python. To do this, the only thing that would be necessary is ensuring that the quantum device was able to retain state between runs.

device.run_then_wait(circuit1, (q1, q2, q3), outputs)
if outputs['m']:
  device.run(circuit2, (q1, q3))
else:
  device.run(circuit3, (q2, q3))

That gives us all the power of Python to run the classical part, which is what it does best, and leaves the quantum part specific to the quantum circuits.

This would remove the need to build a serializable flow control and calculation language into cirq itself.

[95-martin-orion]

Could we turn this inside out? I would think the flow control could remain in Python. {...}

This runs up against a fundamental issue with the current state of quantum computing: waiting for any significant period in the middle of a circuit introduces additional error, as the qubits gradually decohere. Given that these decoherence times are often measured in microseconds, taking the time to pass results out of the control layer to Python and back isn't an option.

[daxfohl]

I see, makes sense. Maybe the solution is something like opengl shaders where there's a C-like language that you code the classical pieces in, and they can reference the quantum circuits somehow.

The thing I'd want to avoid is putting the whole control flow as cirq objects. e.g.

mixed_cicuit =
  cirq.if(
    cirq.ref(circuit1, (q1, q2, q3)),
    'm', 
    cirq.ref(circuit2, (q1, q3)),
    cirq.ref(circuit3, (q2, q3)))

Not too hard to follow for that simple case, but making a whole program from that format: named functions, scopes, complex calculations, seems like it would be a challenge. (Though now that I've typed it out it seems not too bad; just looks like lisp, and it's just an AST so it should be possible to convert back and forth between the two syntaxes and compile onto the device however we want, so who knows).

[daxfohl]

Also allowing users to upload arbitrary Python code to run on google's quantum engine probably isn't the greatest idea from a security standpoint. :)

[daxfohl]

Maybe Web Assembly for the control flow? Similar to how fastly does it for their web workers. So a "package" to run on the quantum device would contain all the circuits plus a wasm file that is the control flow. We can then compile that to native to run on the device's CPU. Since it's WASM, that gives a nice security boundary (which is why fastly uses it), and since we're precompiling it, it should run at native CPU speed. Also it should be portable across devices.

UX would be, user creates quantum circuits in cirq, writes control flow in AssemblyScript, Rust, or whatever that compiles to WASM. Then they call a function in cirq that packages those all up. Simulation should work easily too, as Python already has a wasm interpreter we could run for the control flow code.

This would allow us to use existing languages easily and safely rather than having to create our own "shader language" or build our own AST builders. (Though it doesn't prevent us from doing either of those things -- they could both compile into WASM too. Besides, either of those options will have to compile into something anyway, so may as well go with a standard). I wonder if this provides motivation to create some hybrid QWASM representation at the bottom.

Plenty of details to work through, a lot of it probably depends on how the devices actually work under the hood, just thinking out loud.

[daxfohl]

I'm more thinking this could be a key differentiator. Real world quantum algorithms will require a mixed flow, and being able to standardize a low-level IL for this would be nice. Quantum machines would then take this format to produce the mixed-mode executable.

[daxfohl]

There is also a mature pyverilog library for working with FPGA logic, if we decide FPGA is the better choice due to timings. This may be the more natural choice if all we are doing is feeding forward simple calculations from measurement gates. If we are doing more complex calculations or generating subcircuits on the fly, we'd probably be better off with a software driven solution though, if it can meet the latency constraints. Maybe we end up with a little bit of both.

Also, on second thought the security concerns probably aren't that important, as surely we'll be running these on isolated and hardened environments.