Manual Memory-Compute qubits

[fedimser]

This PR introduces a new way to manually manage Memory qubits. It adds two new operations Std.Memory.MemoryQubitLoad and Std.Memory.MemoryQubitStore that operate on a single qubit and instruct runtime to "load" qubit (move from memory to compute) or "save" it (move from compute to memory).

Example:

Std.ResourceEstimation.EnableMemoryComputeArchitecture(0, 2);
use q = Qubit();
X(q);
Std.Memory.MemoryQubitStore(q);
Std.Memory.MemoryQubitLoad(q);

Conventions:

• Q#'s Qubit is the "quantum value" rather than a location on a physical device. When it is moved between locations (e.g. from "hot" to "cold" area of quantum computer), in Q# it's still the same Q# object. This is why Load and Store act on single qubit and mutate its "type" (compute/memory) rather than action between 2 qubits. At some point Load and Store is translated to 2-qubit operation between memory and compute qubit, but this is hidden from the programmer.
• All qubits become "compute" qubits immediately as allocated.
• Applying gate/measurement to memory qubit is an error.
  • swap_id can be performet only between 2 compute qubits.
  • Reset on memory qubit is allowed.

Notes on implementing these operations in backends:

• These operations currently have effect only in resource estimation, when Std.ResourceEstimation.EnableMemoryComputeArchitecture was called with strategy=2 (which corresponds to manual strategy). They are no-ops in any other backend.
• This allows to have exactly the same algorithm to be resource estimated with and without memory-compute architecture.
• In future we plan to implement these in code generator, by maintaining 2 pools for compute and memory qubits and synthesizing 2-qubit instructions for read/write operations between memory and compute qubit.
• This is why these 2 operations are in Std.Memory, not Std.ResourceEstimation. They describe operations that make sense outside resource estimation, even though currently they are only implemented in resource estimation.
• There will be no need to support these in simulators, they will remain no-op.

Notes on interaction with existing "automatic" memory-compute architecture:

• These features are very similar, so they either need to be merged or be mutually exclusive. I decided to make them mutually exclusive: you either use automatic memory-compute (using strategy=0 or 1) or manual (strategy=2).
• Code for MemoryComputeInfo implementing automatic memory-compute is untouched, I just wrapped it into enum MemoryCompute. By being enum, it forces mutual exlcusivity of memory and compute architecture.
• There are differences between automatic and manual memory-compute:
  • In Manual mode, qubits become "compute" immediately as allocated. In Auto mode, between allocation and first usage qubits are neither compute nor memory, and they become compute only on first usage.
  • When trying to apply computation (gate/measurement) on memory qubit: in Auto mode, it will load the qubit form memory. In "Manual" mode it will result in error. This is added to force users to explicitly add Load instruction. So that if resource estimation succeeds, the user can be sure that they don't accidentally apply computation on memory qubits where they didn't intend to. This can be easily changed to do auto-load, but it is my intention that in manual mode all loads and stores must be explicit.
  • In Auto mode, all inserts into cache are counted as reads, even if they correspond to freshly allocated qubit.
  • Total number of qubits is computed differently.

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for b86379f

Test	This Branch	On Main	Difference
compile core + standard lib	24583163 bytes	24572311 bytes	10852 bytes

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for fbb998b

Test	This Branch	On Main	Difference
compile core + standard lib	24583163 bytes	24572311 bytes	10852 bytes

[swernli]

Resource estimation updates and general infrastructure changes look good. I left a few comments on some things that should be updated and one thought for the future, but I think this is almost ready to go!

[YingrongChen]

Would it be possible to expose this to the Python layer, for example through the QRE inputs?

One use case I imagine is that we build up a Q# file with Store and Load operations, and then run multiple resource estimation from Python while toggling memory-compute layout on or off and varying the compute capacity. We can also error out if the load size exceeds the compute capacity.

It would be painful if we needed to add another input parameter to every Q# circuit that might potentially use the memory-compute layout, and then modify the circuit parameters every time we want to resource-estimate the same circuit under different compute capacities.

[fedimser]

This would be tricky. This information needs to be known during logical resource estimation, so it needs to be an input to logical_counts. Interpreter::logical_counts currently only takes callable and arguments, it doesn't take any "resource estimation parameters".

It's debatable whether using memory-compute architecture is purely resource estimation feature (and therefore using memory-compute should be considered QRE setting). It is now, but in the future when we support error-correcting codes, enabling memory-compute will results in different generated QIR.

I understand that it's inconvenient to declare extra boolean argument in Q# operation. But if this operation expresses two different quantum algorithms based on that argument, extra parameter is the best way to represent that.

[fedimser]

I know this is not perfect solution, but in my Shor's implementation I added a boolean field "use_memory_compute" to ShorsConfig, so at least we don't have to add a new parameter in function signature. It looks like this:

operation PeriodFindingIteration(
    modexp_j_params : ModExpParams,
    modexp_k_params : ModExpParams,
    config : ShorsConfig,
    num_output_qubits : Int
) : (BigInt, BigInt) {
    if (config.use_memory_compute) {
        Std.ResourceEstimation.EnableMemoryComputeArchitecture(0, 2);
    }
    ...
}

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for 6e3b3c4

Test	This Branch	On Main	Difference
compile core + standard lib	24583163 bytes	24572311 bytes	10852 bytes

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for 12e091f

Test	This Branch	On Main	Difference
compile core + standard lib	24583091 bytes	24572311 bytes	10780 bytes

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for caa2c79

Test	This Branch	On Main	Difference
compile core + standard lib	24583051 bytes	24572311 bytes	10740 bytes