search

qiboteam / qibolab

Quantum hardware module and drivers for Qibo.
https://qibo.science
Apache License 2.0
41 stars 10 forks source link

Unrolling with flipping need another batching algorithm #815

Closed Jacfomg closed 4 months ago

Jacfomg commented 5 months ago

We need a smarter way of pack sequences for flipping and RB experiments that takes into account the number of pulses and not the number of measurements or number of sequences. @stavros11 or @alecandido could you take a look on where should this batching take place ?

alecandido commented 5 months ago

There is already a file on its own with batching algorithms: https://github.com/qiboteam/qibolab/blob/main/src/qibolab/instruments/unrolling.py

The currently defined batching functions are pretty simple, and based on @stavros11 checking how many gates, or how many readouts, were empirically fitting in the device.

Improving them is the purpose of #698

stavros11 commented 5 months ago

I think the main issue here, if I understand it correctly, is that @Jacfomg wants to have a different batching algorithm depending on the routine. This is not possible at the driver level because once platform.execute* is called we have no information about what routine called it. Unless the driver does some kind of "guessing" based on how the pulse sequence(s) look and selects a batching algorithm accordingly, but I think this is something we would like to avoid.

Also, I am not sure how valuable these exercises are in the end, since it is an optimization. If unrolling is advertised as a method that is better than just naively looping in Python going with the simplest batching could be sufficient. If we want to optimize further a particular routine (ie. flipping), I am not sure if unrolling is the best solution anyway, or even if there is a single best solution that is optimal for all instruments.

alecandido commented 5 months ago

Ok, I misunderstood the point, thanks @stavros11 for clarifying.

At theoretical level, we could just have a setting in the platform to select the batching algorithm, and dynamically change it in Qibocal.

However, I agree with @stavros11 that it might not be worth. Most likely, if you could improve the batching algorithm it would be an improvement for all routines, because batching depends on the machine constraints. So, if you know that you could improve the batching for a given sequence, please take the time of analyzing the sequence, and find which limitation is too restrictive in the current batching, since most likely that improvement would work even for other similar routines (all in all, unrolling limitations are just memory issues - writing one for each routine would be make Qibocal and Qibolab coupled once more, and they would tend to explode just because a general rule is missing).

Jacfomg commented 5 months ago

I think the main issue here, if I understand it correctly, is that @Jacfomg wants to have a different batching algorithm depending on the routine. This is not possible at the driver level because once platform.execute* is called we have no information about what routine called it. Unless the driver does some kind of "guessing" based on how the pulse sequence(s) look and selects a batching algorithm accordingly, but I think this is something we would like to avoid.

Also, I am not sure how valuable these exercises are in the end, since it is an optimization. If unrolling is advertised as a method that is better than just naively looping in Python going with the simplest batching could be sufficient. If we want to optimize further a particular routine (ie. flipping), I am not sure if unrolling is the best solution anyway, or even if there is a single best solution that is optimal for all instruments.

Yes, it was that, maybe as a start point we could have another parameter on the ExectutionParameters as a way of giving a clue to qibolab on which batching to use. The issue was clear with the flipping as the later sequence involved a 100 pulses while the starting ones have less than 10, similar to RB. I know there are better ways to implement it as all the pulses are the same but for the time being when I tried running it I had to set the max_sequences = 1 as the last sequences were the big ones. Either doing an average of packing long and short sequences together or pack more of the short ones and decrease the packed number as they increase could be a start to actually run flipping_unrolling.

Jacfomg commented 5 months ago

Ok, I misunderstood the point, thanks @stavros11 for clarifying.

At theoretical level, we could just have a setting in the platform to select the batching algorithm, and dynamically change it in Qibocal.

However, I agree with @stavros11 that it might not be worth. Most likely, if you could improve the batching algorithm it would be an improvement for all routines, because batching depends on the machine constraints. So, if you know that you could improve the batching for a given sequence, please take the time of analyzing the sequence, and find which limitation is too restrictive in the current batching, since most likely that improvement would work even for other similar routines (all in all, unrolling limitations are just memory issues - writing one for each routine would be make Qibocal and Qibolab coupled once more, and they would tend to explode just because a general rule is missing).

I agree, but I feel this could be a first step towards building this general rule as we don't know much from how the devices behave on this matter.

alecandido commented 5 months ago

I agree, but I feel this could be a first step towards building this general rule as we don't know much from how the devices behave on this matter.

Then just go dev mode, and use a local instance of qibolab, adding a new batching function (copying the existing one) and attempt to make it optimal. If you obtain any better result, we can try to understand why :)

alecandido commented 5 months ago

The issue was clear with the flipping as the later sequence involved a 100 pulses while the starting ones have less than 10, similar to RB.

Currently https://github.com/qiboteam/qibolab/blob/1c8650b73e019e2c56106ba663a914ce6a088053/src/qibolab/instruments/unrolling.py#L9 is counting the sequences, and https://github.com/qiboteam/qibolab/blob/1c8650b73e019e2c56106ba663a914ce6a088053/src/qibolab/instruments/unrolling.py#L20 is counting the readouts.

But no one of the two is taking a look at the overall number of pulses. Most likely, batch_max_sequences is trying to fit the pulses' memory, assuming all sequences have the same length. But this could be improved using the number of pulses (or even more accurately, by estimating the memory consumed checking even pulses duration, and whether they are rectangular or not). Such an optimization would work for homogeneous as a special case of inhomogeneous ones, so it would only improve over that one.

Jacfomg commented 4 months ago

I will close this as #817 should be a good solution for now.