Manual Memory-Compute qubits#3204
Conversation
ae9b0d8 to
0ea1346
Compare
|
Change in memory usage detected by benchmark. Memory Report for b86379f
|
|
Change in memory usage detected by benchmark. Memory Report for fbb998b
|
swernli
left a comment
There was a problem hiding this comment.
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!
Co-authored-by: Stefan J. Wernli <swernli@microsoft.com>
|
Change in memory usage detected by benchmark. Memory Report for 6e3b3c4
|
|
Change in memory usage detected by benchmark. Memory Report for 12e091f
|
|
Change in memory usage detected by benchmark. Memory Report for caa2c79
|
|
Change in memory usage detected by benchmark. Memory Report for 1c10acb
|
059b4db to
82aa751
Compare
|
Change in memory usage detected by benchmark. Memory Report for 366cc90
|
|
Change in memory usage detected by benchmark. Memory Report for f5a825a
|
|
Change in memory usage detected by benchmark. Memory Report for 4916830
|
74400dc to
b958d59
Compare
|
Change in memory usage detected by benchmark. Memory Report for bb6d9cb
|
|
Change in memory usage detected by benchmark. Memory Report for 90d80b1
|
|
Change in memory usage detected by benchmark. Memory Report for 55efe7f
|
|
Change in memory usage detected by benchmark. Memory Report for 5d78b65
|
|
Change in memory usage detected by benchmark. Memory Report for 003e22f
|
|
Change in memory usage detected by benchmark. Memory Report for 741ce02
|
|
Change in memory usage detected by benchmark. Memory Report for a407432
|
This PR introduces a new way to manually manage Memory qubits. It adds two new operations
Std.Memory.MemoryQubitLoadandStd.Memory.MemoryQubitStorethat 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:
Conventions:
Qubitis 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.swap_idcan be performet only between 2 compute qubits.Reseton memory qubit is allowed.Notes on implementing these operations in backends:
Std.ResourceEstimation.EnableMemoryComputeArchitecturewas called withstrategy=2(which corresponds to manual strategy). They are no-ops in any other backend.Std.Memory, notStd.ResourceEstimation. They describe operations that make sense outside resource estimation, even though currently they are only implemented in resource estimation.Notes on interaction with existing "automatic" memory-compute architecture:
MemoryComputeInfoimplementing automatic memory-compute is untouched, I just wrapped it into enumMemoryCompute. By being enum, it forces mutual exlcusivity of memory and compute architecture.This PR is equivalent to #3159 in a sense that it allows to model algorithms with Memory and Compute qubits with manually moving qubits between Memory and Compute, and it allows to get exactly the same resource estimates. Unlike that PR, this one doesn't require any changes to the Q# language.