Why Software Performance Matters for Quantum Computing

At Zurich Instruments, our mission is to help solve the scaling challenge in quantum computing. How? By providing scalable quantum control solutions with best-in-class signal performance, stable synchronization, and a performant, future-proof control software framework that enables your long-term developments. This frees you from worrying about scaling up the control system, and lets you focus on scaling up the QPU instead - since going to hundreds and then thousands of qubits already poses any number of challenges; managing signal crosstalk, improving quantum coherence, solving signal routing… you name it.

LabOne Q, our software framework for quantum computing, takes a central role in this. It provides you with an interface that lets you concentrate on the science of your experiment, without the distraction of thinking about the details of your control setup. At the heart of LabOne Q sits a compiler that translates from the description of your pulse sequence to machine code, ensuring faithful, sample-precise execution and high experimental throughput. That compiler is now getting a substantial performance boost: we are moving the LabOne Q compiler to Rust.

But before we get to that, let’s have a quick rundown of the inner workings of LabOne Q, to better understand where this change matters most.

LabOne Q - the software framework for scalable quantum computing

When preparing to execute an experiment with LabOne Q, you provide a description of your experiment together with a definition of your control system and its wiring to the LabOne Q compiler. The compiler then prepares the executable payload ready to be transferred and executed on the instruments.

As a first step, the scheduler component of the compiler resolves dependencies between channels, and ensures that any potential hardware constraints are taken into account in the experimental pulse sheet. It then generates an intermediate representation, which contains detailed timing information on all events for all signals involved in the experiment.

In the next step, which we call the code generator, this pulse sheet is used to generate the machine code, waveform data and instrument settings that are needed to execute the experiment. In principle, this step is massively parallelizable since all dependencies have been taken care of during the scheduler step.

LabOne Q was originally developed fully in the Python language. This enabled fast turnaround and rapid prototyping of new functionality and allowed us to remain very close to the needs of our partners throughout the nearly 3 years of LabOne Q’s availability.

In the next phase of our roadmap, software performance moves closer to the center of attention to enable the next scaling milestones. In this phase, we take the proven and reliable mechanics of the LabOne Q compiler and migrate it into a programming language, providing  access to much enhanced performance: Rust.

We have now completed the first phase of this migration, rewriting the code generator in Rust. By starting with the code generator, we realize the largest possible improvement potential first, especially for experiments with many qubits or signal lines.

With this move, we are in good company: Qiskit has also begun to move performance-critical parts of their code to Rust and has made great advances in speed; for example, when transpiling circuits into native gate sets taking into account the qubit connectivity.

What changes for our users

Our migration strategy is designed to minimize the impact on our users and to keep all functionality available. We are migrating the compiler piece-by-piece, all while performing extensive tests to ensure reliability for our users throughout the process. The only impact will be a boost in performance.

See for yourself the progress we have achieved so far:

The above two plots show benchmark measurements of the time spent compiling two large experiment in different LabOne Q versions. One of the experiments is a Ramsey experiment with 201 sweep steps executed in parallel on 180 qubits. The other is a randomized benchmarking (RB) experiment executed in parallel on 4 qubits, with a sequence length of 8192 Clifford gates and 40 random sequences. Starting with version 2.41 from the end of 2024, we increased the overall compilation speed by a factor of 6 for the RB experiment and by a factor 28 for the Ramsey experiment, as shown in Figure 1(a).

Even more substantial is the performance improvement in the code generator part, which was our main focus in the past months. Figure 1(b) shows that that this part got faster by factors of 18 (RB experiment) and over 200 (Ramsey experiment). Clearly the code generator is now no longer the bottleneck, and it is time to move our focus to the remaining parts of the LabOne Q compiler.

Another highlight on our journey to more performance is not concerned with the translation into Rust, but concerns algorithmic improvements. Early on in the effort, we realized that the compilation time did not scale favorably with problem size, as can be seen in Figure 2: instead of the expected linear scaling with size, we observed approximately quadratic scaling. One of the first changes implemented was therefore an improvement in the algorithmic component of the code generator, that managed to restore the expected linear scaling with problem size, as shown in the plot.

All data shown here was obtained on a standard consumer laptop (Macbook Pro 14 inch, 2023 with M2 Pro processor and 16 GB RAM).

More extensive benchmarking data is also available in the LabOne Q user manual. Following through with the open source spirit of LabOne Q, we've also made the benchmarking tools publicly available in our code repository so that you can freely reproduce all data we show.

Next steps

There is much more yet to come; the migration has just begun. All performance-critical parts of LabOne Q will move into a compiled language to be ready for our partners moving to ever larger system sizes. The Python-based domain-specific language (DSL) with its intuitive experiment design and deep low-level access will remain your primary user interface.

I am excited for what is coming in the months ahead, and we will continue to publish our progress on improving performance in the LabOne Q user manual. We invite you to try out the benchmarking yourself, using the ready-to-use example here.