Release news: Qiskit SDK v1.2 is here!Qiskit

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:

• First, before we dig into the key changes and feature improvements introduced with the latest release, it is important to note that v1.2 will be the last Qiskit SDK release that supports Python 3.8. Once Qiskit v1.3 arrives later this year, the minimum required Python version will by Python 3.9.
• With the Qiskit SDK v1.2 release, all circuit infrastructure - e.g., gates, operations, etc. - has been "oxidized," or moved to Rust, enabling speedups in circuit construction and manipulation. Additionally, because of this change, much of the synthesis library now constructs circuits in Rust, producing significant speedups when synthesizing operations such as Cliffords, permutations, or linear functions.
• The quality of transpiled circuits has also been improved through the implementation of a unitary peephole optimization as well as a dense layout in Sabre trials.
• Added a new quality of life improvement when importing the function.

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 10⁴ 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:

• Use of should point to the V2 equivalent .
• Use of should point to its V2 equivalent .
• The should be used instead of .
• The should be used instead of .
• The alias will no longer point to . Best practice now is to explicitly specify the version (either V1 or V2).
• The alias will no longer point to the . Best practice now is to explicitly specify the version (either V1 or V2).

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.

Public link

Please use the above public link if you want to share this noodl on another website.