Release news: Qiskit SDK v1.1.0 is here!

Today, we're excited to announce the release of Qiskit SDK v1.1.0! This marks the first minor version release of the Qiskit SDK’s first major version. Remember, because this a minor release, it will not introduce any breaking changes for users moving from Qiskit SDK v1.0. Read on for a summary of the key highlights, and as always, you can see the full release notes in our documentation, here.

The TL;DR

The biggest updates we’re going to cover in this article include the following:

• QuantumCircuit objects now support typed classical variables. (See the docs page on real-time classical computation for more details.)
• Improvements to the preset transpiler pass managers.
• Continued work re-writing transpiler passes in Rust, yielding more speedups in the runtime of transpilation.
• A number of new transpiler passes, including ElidePermutation and StarPreRouting.

Top new features & improvements

In this section, we’ll cover some of the most important new features and enhancements included in the Qiskit SDK v1.1.0 release. If you want to know more about these changes, or if you want to learn more about the features that didn’t make it into this article, be sure to check out the full list of new features, here.

Support for classical variables in QuantumCircuits

Quantum circuit objects can now contain typed classical variables, allowing for a basic representation of real-time classical computation during circuit execution. These variables are specified as either inputs to the circuit or as scoped variables.

Real-time computations are managed through a new expression and type system found in quantum.circuit.classical. The variables are managed via the qiskit.circuit.classical.expr interface, which introduces new Expr and Var objects to store the output of qubit measurements or target control-flow operations. The following code snippet demonstrates an example of their usage:

You can use these objects wherever classical expressions are supported within a QuantumCircuit. Right now, these are just the expressions of control-flow operations, but we have plans to expand this to gate parameters in the future.

It is important to note here that this new functionality is only a first step towards robust real-time classical computation, and it will take some to time before it is fully supported on hardware and simulator backends. These variables are not yet supported in the primitives interfaces, but will inform their development as they evolve in the future.

Performance

The v1.1.0 minor release also comes with some key improvements to the runtime speed of the transpiler. In particular, the two-qubit synthesis routines in the TwoQubitWeylDecomposition and TwoQubitBasisDecomposer classes have been re-implemented in Rust, yielding significant runtime improvements. These two classes are used by the default unitary synthesis plugin for the UnitarySynthesis pass. The UnitarySynthesis pass synthesizes unitary matrices explicitly added to a QuantumCircuit, and at optimization_level=3 for the preset passmanagers, it also performs two-qubit peephole optimization.

Optimization level 2 transpilation time, Qiskit v1.0.2 vs. Qiskit v1.1.0.

Additionally, we’ve made some key changes in optimization level 2 aimed at striking a better balance between runtime and optimization, and setting up optimization level 2 to serve as the default optimization level in future releases.

For example, we're now running logical optimization passes in the level 2 initialization stage (including ElidePermutations, RemoveDiagonalBeforeMeasure, InverseCancellation, and CommutativeCancellation). We’ve changed the heuristic levels for layout and routing and readjusted the preset passes to give users better results in most of the situations. We’ve also changed the level 2 optimization stage to now run two-qubit peephole optimization with unitary synthesis, but only once outside the optimization loop. After that point, it runs the same optimization loop as before, which just runs commutative cancellation and single-qubit peephole optimization—i.e., the Optimize1qGatesDecomposition pass.

Optimization level 2 output size for QV circuit on Torino, Qiskit v1.0.2 vs. Qiskit v1.1.0.

Lastly, we’ve made a few improvements to the decomposition of multi-controlled X gate (MCXGate) and phase gate (MCPhaseGate) objects, and made the construction of the NLocal family of decompositions (including EfficientSU2, TwoLocal, ExcitationPreserving, and RealAmplitudes) much more efficient. The improvements made to the MCXGate and MCPhaseGate now result in a reduction in the number of gates in the synthesis by more than two orders of magnitude.

New transpiler passes

A few new transpiler passes have also been introduced in this release. Particularly worth mentioning here are the new ElidePermutations transformation pass and the StarPreRouting pass.

The ElidePermutations pass acts as an optimization to be run before any routing or layout is done in the transpilation pipeline. It achieves this by removing swap gates and instead permuting the positions of the virtual qubits in the circuit.

The StarPreRouting transformation pass rewrites sets of two-qubit gates executed in a star connectivity as a linearly connected sequence of two-qubit gates and swaps. A star connectivity is a sequence of two-qubit gates in which one qubit acts as the target or control to several others in a chain. See an example circuit transformation of this pass below:

You can also test out the performance of this pass yourself using the following code snippet:

New deprecations

In this section we’ll cover some of the most important new deprecations introduced with this release. This section aims to highlight things that will now start throwing deprecation warnings and won’t be removed until the release of Qiskit 2.0, pursuant to Qiskit’s official deprecation policy. (Full deprecation policy documentation here.) For guidance on how to deal with deprecation warnings, check out the deprecations section in our previous article here. You can see more detail about the deprecations specific to this release here.

Preparing for Python 3.8 end-of-life

Support for Python 3.8 has now been deprecated, though it will continue to be supported in the next minor release. That release — Qiskit v1.2.0 — will be the last one to come out before Python 3.8 reaches its end-of-life, so it will also be the last release that you can run with Python 3.8. The release after that one — Qiskit v1.3.0 — will not support running with Python 3.8.

Provider deprecation

The abstract base classes Provider and ProviderV1 are now deprecated and will be removed in Qiskit 2.0. The abstraction offered by these interface definitions was not providing a substantial value, given that it only encapsulated the attribute’s name, backends, and a get_backend() method.

A “provider”, as a concept, will continue to exist as a collection of backends. If you’re implementing a provider currently, you can adjust your code by simply removing ProviderV1 as the parent class of your implementation. (As part of this change, you will probably want to add an implementation of get_backend for backwards compatibility.)

Deprecating and generalizing some transpiler passes

There are a few new deprecations that have been introduced amongst the the transpiler passes found in the qiskit.transpiler.passes module. Among these are:

• The pass qiskit.transpiler.passes.CXCancellation was deprecated in favor of InverseCancellation, which is more generic.
• The pass qiskit.transpiler.passes.ALAPSchedule is now deprecated. The pass is replaced by the analysis pass ALAPScheduleAnalysis.
• Similarly, the ASAPSchedule pass is now deprecated and is replaced by the ASAPScheduleAnalysis pass.
• The DynamicalDecoupling pass is being deprecated. Instead, use the PadDynamicalDecoupling pass, which performs the same function but requires a scheduling and analysis pass to be run prior to it.

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.