Open stavros11 opened 1 month ago
This will probably make the code more modular, but I am not sure if it will have any serious impact in performance (most likely no).
We have no concern with performances in Qibolab itself. The only bottlenecks we should care about are networking and the runtime performances of the devices.
We have no concern with performances in Qibolab itself. The only bottlenecks we should care about are networking and the runtime performances of the devices.
That's what I believe as well. Therefore we are probably not gaining much by caching the config
in QmController
, since every time play
is called we are actually reuploading it to the instrument. We could gain something if we were able to tell the instrument to use the last config
, which could be possible, but I haven't looked at it.
We could gain something if we were able to tell the instrument to use the last
config
, which could be possible, but I haven't looked at it.
Yes, that's the falls within networking. If we can save uploads, then we may become more efficient. Take into account that of course we pay a time proportional to the amount of transferred bytes, but there is a fixed amount that is needed just to establish a connection. And I'm not sure if the configs are uploaded within the same connection of the rest of the experiment (since you may upload one config and run several experiments, it wouldn't be unbelievable that the two things are actually independent).
https://github.com/qiboteam/qibolab/pull/933#discussion_r1709791708
It will probably need to drop
config
from an attribute ofQmController
and generate it on-the-fly for every new sequence. This will probably make the code more modular, but I am not sure if it will have any serious impact in performance (most likely no).