Resetting vs discard + populate

[perlinm]

Is there a difference in what happens on hardware for

quantum.reset(qubit)

Versus

quantum.discard(qubit)
qubit = quantum.qubit()

?

Logically, they do the same thing, but I am forced to use the first one (reset) in a function that does not own the qubit.

Makes sense so far. But it's not clear to me whether the two snippets compile down to the same hardware instructions. And if they do not compile to the same hardware instructions, then it's not clear which version should be preferred (due to, say, imposing constraints on the compiler or ion movement).

I would expect the two to compile down to the exact same hardware instructions, but I do not want to make assumptions.

Any guidance?

[ss2165]

In general there is no guarantee they share behaviour, it is runtime dependent.

On Quantinuum hardware also they are different. Reset persists the identity of the ion, discard-then-allocate does not. Meaning in the second case the new ion is in general different to the discarded, the runtime therefore has freedom to pick an ion for you. In terms of optimisation then: use reset if you're sure keeping a handle to the same ion is useful (e.g. if after reset you know it will interact with the same ion it was interacting with before, thereby avoiding transport), and use discard and allocate to allow the runtime to make optimised choices for you (such choices will improve over time as the transport and allocate routines in the runtime improve).

[perlinm]

A proposal: maybe qsystem.reset could promise to preserve ion identity, while quantum.reset could be given the freedom to optimize further?

[ss2165]

Haha I was just about to ask whether those semantics would suit your use case, we will consider it and follow up 👍

[perlinm]

Awesome, thanks!

[ss2165]

@mark-koch points out this is in fact possible with the with_owned guppy feature:

from guppylang import guppy
from guppylang.std.quantum import qubit, discard
from guppylang.std.builtins import owned
from guppylang.std.mem import with_owned

@guppy
def borrowed_reset(q: qubit) -> None:
    def discard_and_realloc(q: qubit @owned) -> tuple[None, qubit]:
        discard(q)
        return None, qubit()

    with_owned(q, discard_and_realloc)

[perlinm]

Thanks! I think this fully solves my problem for now. I still think relaxing constraints on quantum.reset is better in the long term, though, as it opens opportunities for compiler optimizations.