-
Notifications
You must be signed in to change notification settings - Fork 6
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
Prototype a "lazify-measurement" hugr->hugr pass #432
Comments
Further thoughts: I have implemented the minimum pass in the linked PR. This replaces I think we should rename Lazy -> Future. We should remove the In the In the future we can introduce a |
The need for if (given) we do need |
They will lower to reference counted resources, so they are much the same as They are not exactly the same as |
Ah, yes, true. The writing is captured in the closure of how to compute the value. And (importantly) this closure, even tho referred to by the non-linear/ Agreed Lazy/Future is a useful general thing to have. Is it any easier if we do something Qubit/measure-specific? I'm not sure it is (==> this is "develop I note also that there is a counterargument that we should do measurement early, to free up qubits for dynamic allocation. The usual instruction-scheduling/register-allocation phase-order problem, one might say ;-) :-( |
To be clear, nothing here constructs a
This
This is why I have separated the
Please do see I have dreams of introducing a One can imagine we would would have different kinds of futures(in the future lol), representing different future-like interfaces offered by the runtime. In this world we would identify different kinds of futures by another type param. |
The h-series runtime wants to be lazy in using the results of measurements, to facilitate runtime pipelining.
I suggest we can achieve this with the following:
lazy
extension withLazy<T>
lift<T>: T -> Lazy<T>
read<T>: Lazy<T> -> T
measure: Qubit -> (Qubit, Lazy<BOOL_T>)
BOOL_T
result of "quantum.tket2.measure":Conditional
control input, output-of-DataflowBlock
control input, output-of-TailLoop
control input, indirect call, call to public function, or custom op input:read
the Lazy<BOOL_T> .Lazy<BOOL_T>
and iterateNote that here a public function is either a
FuncDecl
or a function which is the target ofLoadFunction
I intend to start with the
Lazy<T>
type being linear, and addingdup
andfree
functions. I anticipate that lowerings will want to manage waitable "handles".dup
will lower to "increment reference count" andfree
will lower to "decrement reference count". If making it linear ends up being too hard I will switch to non-linear to get something working.This code should live in
tket2-hseries
force_order
afterlazify-measurements
. Pull quantum ops to the front and push future reads to the back. #492The text was updated successfully, but these errors were encountered: