Pulse storing

[Jacfomg]

It would be relevant to look into ways to store pulses in a driver during the experiments and reuse them during unrolling routines to avoid uploading too many different waveforms that would make the devices (at least, Zurich) crash sooner than expected. This would also lead to faster compilation steps that may be the bottleneck now.

After looking for some information, Zurich calls it placeholder waveforms and claims on a last year post their performance, https://www.zhinst.com/others/en/blogs/five-tips-boost-your-qubit-measurements

I think this would be related to https://github.com/qiboteam/qibolab/issues/693

[alecandido]

In which way is this different from #671?

In any case, how it is (not) done in QM is pretty straightforward: for each experiment, you upload your waveforms, and we should try to upload only once per shape (a single representative for the whole orbit under translations and dilations and different modulations - even though time dilations, i.e. the duration sweeper, are a different story). I'm not even sure if it's worth to avoid thinking about re-uploading even less (share across multiple experiments).

If we can translate and compile our pulses this way, so much the better :) (and most likely we will only need the shapes as callables)

[Jacfomg]

I think the #671 feature would be more oriented towards something like variational circuits where some pulses are fixed but other might change one or some at a time on following executions for which we would use this feature if I understood it correctly. This might be harder to implement.

Storing the pulses might be easier and it is what you described. I found limitations with Zurich regarding how many different waveforms you could upload even if at the end they were the same and were being upload several times with the unrolling, so I assume the device wasn't taken care of it properly.

[alecandido]

I think the #671 feature would be more oriented towards something like variational circuits where some pulses are fixed but other might change one or some at a time on following executions for which we would use this feature if I understood it correctly. This might be harder to implement.

But, if the pulses are stored in memory anyhow, most likely the difference is only in the way you upload them, I guess. I.e.:

• normally, you would pay the price of reuploading even pulses that you already defined (so if the sequence is A-B(n)-C-D and you have to upload $N$ times, then you would upload $N$ times each element of the sequence)
• if you unroll, you would upload only the different one, but all at once (so A, C, and D only once, but all the $N$ B(n)), with the chance of hitting the memory limitations (and thus the requirement of batching, and a few potential reuploads of A, C, and D, once per batch)
• with replacement (if I understood) you will reupload every time only B(n), but you still pay the price of reuploading every time you execute - so losing the main benefit of unrolling

It's true that for specific situations there might be some convenience in replacing vs unrolling (e.g. if you have a very long sequence, with a few replacements, such that you could only fit one per batch), but they seem really borderline, and I'm not sure is worth the effort to support (for unrolling we also have an intuitive API, just passing multiple sequences, but for the replacement we should mark those to be replaced, or identify them automatically - which is possible, but less transparent and heavier to maintain).

I'm tempted to say that this issue is relevant, as a better support to the unrolling, but #671 I'm not sure we want to implement.

[Jacfomg]

Yeah, but I think right now the unrolling would upload A, C, and D multiple times per sequence (at least in Zurich). If we manage to make it work as you described it would be perfect and the unrolling and waveform replacement, I guess, would be mostly the same. Ideally if we change the Pulse an easy way of telling the pulses should be the same just in another sequence would be a good idea.

[alecandido]

This is already happening in Qblox (more or less, at least if it fits a single sequencer), and what should happen in QM, given that they are asking every time to upload the waveforms (that are not yet deduplicated, but they should).

I opened an issue related #716, but I've just found out that is slightly more complicated than I thought. It would be helpful to know if it is more complicate also for Zurich and QM.