We have a significant code library with lots of helper functions for standard operations (optical pumping, sideband cooling, detection, etc...) that all our experiments inherit from, but this leads to quite long compilation times. Any of my experiments take nearly 10 seconds to compile, and this is causing issues with some of the things I'd like to do like frequent recalibrations or parameter optimization. My main question is: When exactly is code (re-)compiled? If I have a non-kernel run() function that then calls an @kernel run_core() function multiple times, is it being recompiled each time? Or is it only compiled once? Is there any way to re-use previously compiled code?

Secondly, is there anything I can do to speed up compilation times? 10 seconds seems excessive. I have no interest in re-writing our extensive codebase to be compatible with a pre-alpha version of NAC3 with no np.array support. Short of that, do you have any recommendations? ARTIQ 7 is running in a nix environment in a docker container on an ubuntu machine (we have a container on this machine for each our 6 crates). I have 30 parameters that need regular recalibration, leading to 30 experiments being submitted each time I run a full recalibration. This means 5 minutes spent just compiling.

I have not attached any code because uploading our full codebase seems excessive, but I am happy to provide more details or snippets of any specific aspects.

    Re-program your @kernel functions to retrieve experimental parameter values from your Ubuntu machine at run-time via calls to @rpc functions. On your Ubuntu machine, set things up in such a way that you can change parameter values in real time, e.g. by modifying a file from which the @rpc functions read the parameter values.

    As far as I know, calls to @rpc functions are the only way to change a @kernel-function's behavior without re-compiling it.

    Notes:

    • If the @rpc-functions take so long that you run into RTIO-underflows, stick a new PCIe card with 1x Gbit Ethernet port into your Ubuntu machine and connect your Kasli master directly to that port.
    • If you still have problems, change the delays in your experiment code or swap out your Kaslis for Kasli SoCs.

    In short, I don't think there is a painless way.

      dtsevas Thanks for your suggestions!

      I had attempted something similar previously, where I had an experiment that would sit in the kernel and check for a dataset to change, in which case it would re-run the data collection function, but this kept totally crashing the crate - no error message, and required a full power cycle before any experiments would execute on the core. I wasn't sure how to debug that with no error messages, but perhaps this is the direction I should go. At least with @rpc calls there isn't the on-core polling required, so maybe it'll be smoother sailing.

        debry pre-alpha version of NAC3 with no np.array support

        NAC3 currently supports more numpy array features than the legacy compiler.