08/21/2024 | News release | Distributed by Public on 08/21/2024 08:35
Today, we're excited to announce the release of Qiskit SDK v1.2! The latest minor version release includes a number of important new features and improvements, all aimed at boosting the Qiskit SDK's industry-leading performance and functionality. Read on for a summary of key highlights, and as always, those who would like more detail can find the full release notes in our documentation here.
Since transitioning to the v1.x era with the release of its first major version earlier this year, we have been laser-focused on making the Qiskit SDK the most powerful, high-performant quantum SDK in the world. Our goal is to ensure that researchers and developers can use Qiskit as a high-performance tool for efficiently running utility-scale workloads. That focus continues with the new v1.2 release, which brings significant enhancements to the performance and overall quality of the Qiskit transpiler.
The TL;DR
Here's a quick overview of the biggest takeaways from this article:
Top new performance improvements
This year, the Qiskit SDK has proven itself as a powerful, high-performance tool for running utility-scale quantum workloads. At the same time, we're continuously developing new features and enhancements to make it even more performant. Let's take a look at some changes we've introduced with the Qiskit v1.2 release that aim to do just that.
If you want to learn more about these changes, or if you're looking for details on some of the new Qiskit v1.2 features that didn't make it into this article, be sure to check out the full release notes, which you'll find in our documentation here.
Changes to circuit infrastructure
As we mentioned above, much of the infrastructure for building objects has been rewritten in Rust. In particular, the Qiskit SDK's standard gate library now possesses a native representation in Rust. This allows for much faster circuit construction and manipulation.
This work opens up pathways that will allow us to further accelerate other components of the Qiskit software stack by enabling more of Qiskit to execute from the Rust domain without interacting with Python at all. In the new Qiskit SDK v1.2 release, this has led to some noticeable improvements in transpilation speed. It has also enabled significant speedups in the synthesis library, which is now able to now generate circuits entirely in Rust.
Below is a plot of the construction time for a 400-qubit circuit as a function of the number of entangling layers. Comparing against v1.0, one can see an almost 2.8x improvement in speed.
Additionally, because of the memory management efficiencies in Rust, the runtime for copying very large circuits has also improved significantly.
Circuit synthesis and transpilation improvements
The changes in the circuit infrastructure detailed above have enabled further improvements to the Qiskit SDK's circuit synthesis and transpilation processes. Large parts of the synthesis library now construct circuits in Rust. This has enabled enormous improvements in the runtime of synthesis operations, including improvements in the synthesis of permutations, improvements in Cliffords, and improvements in the synthesis of single and two-qubit unitary operators.
To demonstrate the scale of these performance improvements, we can look at a few runtime metrics and compare them against the two previous minor releases of the Qiskit SDK. First, let's take a look at the runtime of the two-qubit unitary synthesis methods averaged over 104 random inputs:
Here, you can see that the newest features found in v1.2.0 produce an almost 100-fold improvement compared against v1.0.2, and an almost 5-fold improvement as compared to v1.1.1.
In the move to Rust, we've also improved one of the Clifford synthesis algorithms (), demonstrating a nearly 500-fold improvement in runtime as compared to v1.1.1 and v1.0.2:
Qiskit v1.2 also includes additional transpilation tuning for level 2, which will be the default optimization level in Qiskit SDK v1.3. The new tuning selects better starting points when choosing a qubit layout and routing via the Sabre algorithm. Altogether, this tuning has resulted in significant improvements to the quality of transpilation.
In the example below, we show how transpiling to different target gates has consistently resulted in shallower circuits as we've progressed through each minor release of the v1.x cycle (see the code for this benchmark test here):
Like its predecessors, Qiskit SDK v1.2 also brings new improvements in runtime speed over previous v1.x minor releases. This means that transpilation for the example shown above was not only better in terms of quality, it was also faster:
Top new features
Among the various feature improvements that have come with this release, one new quality-of-life improvement deserves a particular emphasis: Moving forward, you'll have two new import path options for the function.
This change was made to more accurately reflect the importance of this function, which is by far the most frequently used function for building transpilation pipelines. You can now import this function using either of the following options.
Option 1:
Option 2:
Either option can be used in addition to the default path: .
Peephole transpilation optimization
One of the key improvements to the transpiler is that it now uses two-qubit unitary peephole optimization during the stage prior to layout and routing at optimization levels 2 and 3, resulting in improved runtime and quality. In previous releases, we only ran this optimization after layout and routing.
Two-qubit unitary peephole optimization collects two-qubit blocks in the circuit and replaces them with a unitary matrix representation. This matrix is then synthesized using fewer gates than the block it replaces. To add this technique to the stage, we run the pass prior to layout and routing, replacing the blocks of gates with their matrix representation.
This has a few benefits. It shrinks the number of gates in the circuit, which in turn simplifies the layout and routing problem by reducing the number of individual operations it contains. It also has the potential to help us find larger two-qubit blocks. When swap gates are added to the circuit after routing is run, these swaps can break up a block that existed prior to routing.
Additionally, we've added a new transpiler pass, , which performs additional analysis on the two-qubit unitary matrices generated by and determines whether any are the tensor product of two single-qubit gates. In those cases, we decompose the two-qubit block into two single-qubit unitary matrices. This optimization can be difficult to detect after the routing stage runs and adds additional swap gates to the circuit.
New circuit features
Several new classes and functions have been added to the library. Among these is a class to natively represent Quantum Fourier Transforms, as well as a new module which allows for the generation of random Clifford circuits with gates from the standard library.
The new class is an alternative implementation of a Quantum Fourier transform that defers its synthesis until transpilation. This differs from the existing class, which eagerly synthesizes a circuit when it's created. The class remains in place for backwards compatibility. However, deferring the synthesis until transpilation gives us more opportunities to control how the QFT circuit will be synthesized and enables a better realization depending on the target backend.
The new class brings two new HLS synthesis plugins to Qiskit: and . The former synthesizes a QFT circuit assuming an all-to-all connectivity, while the latter synthesizes a QFT circuit assuming linear nearest-neighbor connectivity. Performing a QFT is often part of a larger algorithm such as quantum phase estimation, so deferring synthesis to the transpiler will let you determine the best synthesis choice for using QFT in your particular circuit.
Lastly, the module now contains a new function, , which generates a random Clifford circuit with gates from the standard library and inputs for both the number of qubits and total number of gates. A quick example of its usage is shown below:
New deprecations
Primitives deprecations
The unversioned reference primitive implementations have been deprecated. When invoking a primitive or reference primitive implementation, you must now explicitly specify them by their version (i.e. V1 and V2). Additionally reference implementations and their associated aliases are now deprecated in favor of their V2 counterparts. However, the V1 definitions (e.g., ) have not been deprecated. A few examples of what to change include:
BackendV1 deprecation
The class has been deprecated and will be removed in the Qiskit v2.0 release. If you're using a provider package that is still providing objects, that package will need to be updated to use the newer interface. Once you do this, you will find there are different access patterns for querying the details of a backend. You can refer to the migration guide for more information.
Looking ahead to Qiskit SDK v1.3
Although this article is all about Qiskit SDK v1.2, there are also a few important upcoming changes that users should prepare for ahead of the transition to Qiskit v1.3. These include:
Python 3.8 end-of-life
As mentioned above, the v1.2.0 release will be the last one to support Python 3.8. Once Qiskit v1.3 is released, the minimum version of Python supported will be Python 3.9. This change occurred because Python 3.8 will reach its end-of-life in October of this year, before Qiskit v1.3 is planned to be released.
Changes to default optimization level
In the next minor release, Qiskit v1.3.0, the default optimization level for the function will change from 1 to 2. Optimization level 2 will also become the default for the function, which currently doesn't have a default. We feel this provides a better value for most users given the recent performance improvements in the transpiler passes, and that it is likely to deliver the most optimal trade-off between the transpilation runtime and quality of the transpiled circuits.
And there you have it! The most important details of the latest release. Remember, if you want to put ideas forward for future versions of Qiskit, you can always open a GitHub issue to request a feature or report a bug. And if you want to follow what's coming up in the next release you can take a look at the upcoming Qiskit SDK milestones.
Many people contributed to this release. Special thanks to (in alphabetical order):
This blog post was written by Kaelyn Ferris with contributions from Abby Mitchell, Blake Johnson, Jake Lishman, Kevin Krsulich, Luciano Bello, Matthew Treinish, and Robert Davis.