The ahash hasher offers better performace as a drop in replacement for
the stdlib hash algorithm. This is a large reason we use the hashbrown
crate for our HashMap type in Qiskit (along with rayon support). The
indexmap crate doesn't use ahash by default however, so we typically
switch to it anywhere we use IndexMap or IndexSet to match the lookup
performance of hashbrown in places where we need to preserve insertion
order. However, there were a couple of spots where we missed this in the
rust code, this commit corrects these oversights.
* Fix parsing of huge OpenQASM 2 conditionals
We fixed handling of giant integers in gate expression positions
gh-12140, and this commit fixes the handling in conditionals.
Unfortunately, this means pulling in big-int handling properly; the
integers simply _are_ bigints, and we're not immediately converting them
into something else.
The need to support this may influence how the Rust-space data models of
`QuantumCircuit` evolve.
* Move `num-bigint` dependency to workspace
* Rebalance `CircuitInstruction` and `PackedInstruction`
This is a large overhaul of how circuit instructions are both stored in
Rust (`PackedInstruction`) and how they are presented to Python
(`CircuitInstruction`). In summary:
* The old `OperationType` enum is now collapsed into a manually managed
`PackedOperation`. This is logically equivalent, but stores a
`PyGate`/`PyInstruction`/`PyOperation` indirectly through a boxed
pointer, and stores a `StandardGate` inline. As we expect the vast
majority of gates to be standard, this hugely reduces the memory
usage. The enumeration is manually compressed to a single pointer,
hiding the discriminant in the low, alignment-required bytes of the
pointer.
* `PackedOperation::view()` unpacks the operation into a proper
reference-like enumeration `OperationRef<'a>`, which implements
`Operation` (though there is also a `try_standard_gate` method to get
the gate without unpacking the whole enumeration).
* Both `PackedInstruction` and `CircuitInstruction` use this
`PackedOperation` as the operation storage.
* `PackedInstruction` is now completely the Rust-space format for data,
and `CircuitInstruction` is purely for communication with Python.
On my machine, this commit brings the utility-scale benchmarks to within
10% of the runtime of 1.1.0 (and some to parity), despite all the
additional overhead.
Changes to accepting and building Python objects
------------------------------------------------
* A `PackedInstruction` is created by copy constructor from a
`CircuitInstruction` by `CircuitData::pack`. There is no `pack_owned`
(really, there never was - the previous method didn't take ownership)
because there's never owned `CircuitInstruction`s coming in; they're
Python-space interop, so we never own them (unless we clone them)
other than when we're unpacking them.
* `PackedInstruction` is currently just created manually when not coming
from a `CircuitInstruction`. It's not hard, and makes it easier to
re-use known intern indices than to waste time re-interning them.
There is no need to go via `CircuitInstruction`.
* `CircuitInstruction` now has two separated Python-space constructors:
the old one, which is the default and takes `(operation, qubits,
clbits)` (and extracts the information), and a new fast-path
`from_standard` which asks only for the standard gate, qubits and
params, avoiding operator construction.
* To accept a Python-space operation, extract a Python object to
`OperationFromPython`. This extracts the components that are separate
in Rust space, but joined in Python space (the operation, params and
extra attributes). This replaces `OperationInput` and
`OperationTypeConstruct`, being more efficient at the extraction,
including providing the data in the formats needed for
`PackedInstruction` or `CircuitInstruction`.
* To retrieve the Python-space operation, use
`CircuitInstruction::get_operation` or
`PackedInstruction::unpack_py_op` as appropriate. Both will
cache and reuse the op, if `cache_pygates` is active. (Though note
that if the op is created by `CircuitInstruction`, it will not
propagate back to a `PackedInstruction`.)
Avoiding operation creation
---------------------------
The `_raw_op` field of `CircuitInstruction` is gone, because `PyGate`,
`PyInstruction` and `PyOperation` are no longer pyclasses and no longer
exposed to Python. Instead, we avoid operation creation by:
* having an internal `DAGNode::_to_circuit_instruction`, which returns a
copy of the internal `CircuitInstruction`, which can then be used with
`CircuitInstruction.replace`, etc.
* having `CircuitInstruction::is_standard_gate` to query from Python
space if we should bother to create the operator.
* changing `CircuitData::map_ops` to `map_nonstandard_ops`, and having
it only call the Python callback function if the operation is not an
unconditional standard gate.
Memory usage
------------
Given the very simple example construction script:
```python
from qiskit.circuit import QuantumCircuit
qc = QuantumCircuit(1_000)
for _ in range(3_000):
for q in qc.qubits:
qc.rz(0.0, q)
for q in qc.qubits:
qc.rx(0.0, q)
for q in qc.qubits:
qc.rz(0.0, q)
for a, b in zip(qc.qubits[:-1], qc.qubits[1:]):
qc.cx(a, b)
```
This uses 1.5GB in max resident set size on my Macbook (note that it's
about 12 million gates) on both 1.1.0 and with this commit, so we've
undone our memory losses. The parent of this commit uses 2GB.
However, we're in a strong position to beat 1.1.0 in the future now;
there are two obvious large remaining costs:
* There are 16 bytes per `PackedInstruction` for the Python-operation
caching (worth about 180MB in this benchmark, since no Python
operations are actually created).
* There is also significant memory wastage in the current
`SmallVec<[Param; 3]>` storage of the parameters; for all standard
gates, we know statically how many parameters are / should be stored,
and we never need to increase the capacity. Further, the `Param` enum
is 16 bytes wide per parameter, of which nearly 8 bytes is padding,
but for all our current use cases, we only care if _all_ the
parameters or floats (for everything else, we're going to have to
defer to Python). We could move the discriminant out to the level of
the parameters structure, and save a large amount of padding.
Further work
------------
There's still performance left on the table here:
* We still copy-in and copy-out of `CircuitInstruction` too much right
now; we might want to make all the `CircuitInstruction` fields
nullable and have `CircuitData::append` take them by _move_ rather
than by copy.
* The qubits/clbits interner requires owned arrays going in, but most
interning should return an existing entry. We probably want to switch
to have the interner take references/iterators by default, and clone
when necessary. We could have a small circuit optimisation where the
intern contexts reserve the first n entries to use for an all-to-all
connectivity interning for up to (say) 8 qubits, since the transpiler
will want to create a lot of ephemeral small circuits.
* The `Param` vectors are too heavy at the moment; `SmallVec<[Param;
3]>` is 56 bytes wide, despite the vast majority of gates we care
about having at most one single float (8 bytes). Dead padding is a
large chunk of the memory use currently.
* Fix clippy in no-gate-cache mode
* Fix pylint unused-import complaints
* Fix broken assumptions around the gate model
The `compose` test had a now-broken assumption, because the Python-space
`is` check is no longer expected to return an identical object when a
standard gate is moved from one circuit to another and has its
components remapped as part of the `compose` operation. This doesn't
constitute the unpleasant deep-copy that that test is preventing. A
custom gate still satisfies that, however, so we can just change the
test.
`DAGNode::set_name` could cause problems if it was called for the first
time on a `CircuitInstruction` that was for a standard gate; these would
be created as immutable instances. Given the changes in operator
extraction to Rust space, it can now be the case that a standard gate
that comes in as mutable is unpacked into Rust space, the cache is some
time later invalidated, and then the operation is recreated immutably.
* Fix lint
* Fix minor documentation
This encapsulates a lot of the common logic around Python sequence-like
indexers (`SliceOrInt`) into iterators that handle adapting negative
indices and slices in `usize` for containers of a given size.
These indexers now all implement `ExactSizeIterator` and
`DoubleEndedIterator`, so they can be used with all `Iterator` methods,
and can be used (with `Iterator::map` and friends) as inputs to
`PyList::new_bound`, which makes code simpler at all points of use.
The special-cased uses of this kind of thing from `CircuitData` are
replaced with the new forms. This had no measurable impact on
performance on my machine, and removes a lot noise from error-handling
and highly specialised functions.
* Add infrastructure for gates, instruction, and operations in Rust
This commit adds a native representation of Gates, Instruction, and
Operations to rust's circuit module. At a high level this works by
either wrapping the Python object in a rust wrapper struct that tracks
metadata about the operations (name, num_qubits, etc) and then for other
details it calls back to Python to get dynamic details like the
definition, matrix, etc. For standard library gates like Swap, CX, H,
etc this replaces the on-circuit representation with a new rust enum
StandardGate. The enum representation is much more efficient and has a
minimal memory footprint (just the enum variant and then any parameters
or other mutable state stored in the circuit instruction). All the gate
properties such as the matrix, definiton, name, etc are statically
defined in rust code based on the enum variant (which represents the
gate).
The use of an enum to represent standard gates does mean a change in
what we store on a CircuitInstruction. To represent a standard gate
fully we need to store the mutable properties of the existing Gate class
on the circuit instruction as the gate by itself doesn't contain this
detail. That means, the parameters, label, unit, duration, and condition
are added to the rust side of circuit instrucion. However no Python side
access methods are added for these as they're internal only to the Rust
code. In Qiskit 2.0 to simplify this storage we'll be able to drop, unit,
duration, and condition from the api leaving only label and parameters.
But for right now we're tracking all of the fields.
To facilitate working with circuits and gates full from rust the
setting the `operation` attribute of a `CircuitInstruction` object now
transltates the python object to an internal rust representation.
For standard gates this translates it to the enum form described earlier,
and for other circuit operations 3 new Rust structs: PyGate,
PyInstruction, and PyOperation are used to wrap the underlying Python
object in a Rust api. These structs cache some commonly accessed static
properties of the operation, such as the name, number of qubits, etc.
However for dynamic pieces, such as the definition or matrix, callback
to python to get a rust representation for those.
Similarly whenever the `operation` attribute is accessed from Python
it converts it back to the normal Python object representation. For
standard gates this involves creating a new instance of a Python object
based on it's internal rust representation. For the wrapper structs a
reference to the wrapped PyObject is returned.
To manage the 4 variants of operation (`StandardGate`, `PyGate`,
`PyInstruction`, and `PyOperation`) a new Rust trait `Operation` is
created that defines a standard interface for getting the properties
of a given circuit operation. This common interface is implemented for
the 4 variants as well as the `OperationType` enum which wraps all 4
(and is used as the type for `CircuitInstruction.operation` in the
rust code.
As everything in the `QuantumCircuit` data model is quite coupled moving
the source of truth for the operations to exist in Rust means that more
of the underlying `QuantumCircuit`'s responsibility has to move to Rust
as well. Primarily this involves the `ParameterTable` which was an
internal class for tracking which instructions in the circuit have a
`ParameterExpression` parameter so that when we go to bind parameters we
can lookup which operations need to be updated with the bind value.
Since the representation of those instructions now lives in Rust and
Python only recieves a ephemeral copy of the instructions the
ParameterTable had to be reimplemented in Rust to track the
instructions. This new parameter table maps the Parameter's uuid (as a
u128) as a unique identifier for each parameter and maps this to a
positional index in the circuit data to the underlying instruction using
that parameter. This is a bit different from the Python parameter table
which was mapping a parameter object to the id of the operation object
using that parmaeter. This also leads to a difference in the binding
mechanics as the parameter assignment was done by reference in the old
model, but now we need to update the entire instruction more explicitly
in rust. Additionally, because the global phase of a circuit can be
parameterized the ownership of global phase is moved from Python into
Rust in this commit as well.
After this commit the only properties of a circuit that are not defined
in Rust for the source of truth are the bits (and vars) of the circuit,
and when creating circuits from rust this is what causes a Python
interaction to still be required.
This commit does not translate the full standard library of gates as
that would make the pull request huge, instead this adds the basic
infrastructure for having a more efficient standard gate representation
on circuits. There will be follow up pull requests to add the missing
gates and round out support in rust.
The goal of this pull request is primarily to add the infrastructure for
representing the full circuit model (and dag model in the future) in
rust. By itself this is not expected to improve runtime performance (if
anything it will probably hurt performance because of extra type
conversions) but it is intended to enable writing native circuit
manipulations in Rust, including transpiler passes without needing
involvement from Python. Longer term this should greatly improve the
runtime performance and reduce the memory overhead of Qiskit. But,
this is just an early step towards that goal, and is more about
unlocking the future capability. The next steps after this commit are
to finish migrating the standard gate library and also update the
`QuantumCircuit` methods to better leverage the more complete rust
representation (which should help offset the performance penalty
introduced by this).
Fixes: #12205
* Fix Python->Rust Param conversion
This commit adds a custom implementation of the FromPyObject trait for
the Param enum. Previously, the Param trait derived it's impl of the
trait, but this logic wasn't perfect. In cases whern a
ParameterExpression was effectively a constant (such as `0 * x`) the
trait's attempt to coerce to a float first would result in those
ParameterExpressions being dropped from the circuit at insertion time.
This was a change in behavior from before having gates in Rust as the
parameters would disappear from the circuit at insertion time instead of
at bind time. This commit fixes this by having a custom impl for
FromPyObject that first tries to figure out if the parameter is a
ParameterExpression (or a QuantumCircuit) by using a Python isinstance()
check, then tries to extract it as a float, and finally stores a
non-parameter object; which is a new variant in the Param enum. This
new variant also lets us simplify the logic around adding gates to the
parameter table as we're able to know ahead of time which gate
parameters are `ParameterExpression`s and which are other objects (and
don't need to be tracked in the parameter table.
Additionally this commit tweaks two tests, the first is
test.python.circuit.library.test_nlocal.TestNLocal.test_parameters_setter
which was adjusted in the previous commit to workaround the bug fixed
by this commit. The second is test.python.circuit.test_parameters which
was testing that a bound ParameterExpression with a value of 0 defaults
to an int which was a side effect of passing an int input to symengine
for the bind value and not part of the api and didn't need to be
checked. This assertion was removed from the test because the rust
representation is only storing f64 values for the numeric parameters
and it is never an int after binding from the Python perspective it
isn't any different to have float(0) and int(0) unless you explicit
isinstance check like the test previously was.
* Fix qasm3 exporter for std gates without stdgates.inc
This commit fixes the handling of standard gates in Qiskit when the user
specifies excluding the use of the stdgates.inc file from the exported
qasm. Previously the object id of the standard gates were used to
maintain a lookup table of the global definitions for all the standard
gates explicitly in the file. However, the rust refactor means that
every time the exporter accesses `circuit.data[x].operation` a new
instance is returned. This means that on subsequent lookups for the
definition the gate definitions are never found. To correct this issue
this commit adds to the lookup table a fallback of the gate name +
parameters to do the lookup for. This should be unique for any standard
gate and not interfere with the previous logic that's still in place and
functional for other custom gate definitions.
While this fixes the logic in the exporter the test is still failing
because the test is asserting the object ids are the same in the qasm3
file, which isn't the case anymore. The test will be updated in a
subsequent commit to validate the qasm3 file is correct without using
a hardcoded object id.
* Fix base scheduler analysis pass duration setting
When ALAPScheduleAnalysis and ASAPScheduleAnalysis were setting the
duration of a gate they were doing `node.op.duration = duration` this
wasn't always working because if `node.op` was a standard gate it
returned a new Python object created from the underlying rust
representation. This commit fixes the passes so that they modify the
duration and then explicit set the operation to update it's rust
representation.
* Fix python lint
* Fix last failing qasm3 test for std gates without stdgates.inc
While the logic for the qasm3 exporter was fixed
in commit a6e69ba4c9 to handle the edge
case of a user specifying that the qasm exporter does not use the
stdgates.inc include file in the output, but also has qiskit's standard
gates in their circuit being exported. The one unit test to provide
coverage for that scenario was not passing because when an id was used
for the gate definitions in the qasm3 file it was being referenced
against a temporary created by accessing a standard gate from the
circuit and the ids weren't the same so the reference string didn't
match what the exporter generated. This commit fixes this by changing
the test to not do an exact string comparison, but instead a line by
line comparison that either does exact equality check or a regex search
for the expected line and the ids are checked as being any 15 character
integer.
* Remove superfluous comment
* Cache imported classes with GILOnceCell
* Remove unused python variables
* Add missing file
* Update QuantumCircuit gate methods to bypass Python object
This commit updates the QuantumCircuit gate methods which add a given
gate to the circuit to bypass the python gate object creation and
directly insert a rust representation of the gate. This avoids a
conversion in the rust side of the code. While in practice this is just
the Python side object creation and a getattr for the rust code to
determine it's a standard gate that we're skipping. This may add up over
time if there are a lot of gates being created by the method.
To accomplish this the rust code handling the mapping of rust
StandardGate variants to the Python classes that represent those gates
needed to be updated as well. By bypassing the python object creation
we need a fallback to populate the gate class for when a user access the
operation object from Python. Previously this mapping was only being
populated at insertion time and if we never insert the python object
(for a circuit created only via the methods) then we need a way to find
what the gate class is. A static lookup table of import paths and class names
are added to `qiskit_circuit::imports` module to faciliate this and
helper functions are added to facilitate interacting with the class
objects that represent each gate.
* Deduplicate gate matrix definitions
* Fix lint
* Attempt to fix qasm3 test failure
* Add compile time option to cache py gate returns for rust std gates
This commit adds a new rust crate feature flag for the qiskit-circuits
and qiskit-pyext that enables caching the output from
CircuitInstruction.operation to python space. Previously, for memory
efficiency we were reconstructing the python object on demand for every
access. This was to avoid carrying around an extra pointer and keeping
the ephemeral python object around longer term if it's only needed once.
But right now nothing is directly using the rust representation yet and
everything is accessing via the python interface, so recreating gate
objects on the fly has a huge performance penalty. To avoid that this
adds caching by default as a temporary solution to avoid this until we
have more usage of the rust representation of gates.
There is an inherent tension between an optimal rust representation
and something that is performant for Python access and there isn't a
clear cut answer on which one is better to optimize for. A build time
feature lets the user pick, if what we settle on for the default doesn't
agree with their priorities or use case. Personally I'd like to see us
disable the caching longer term (hopefully before releasing this
functionality), but that's dependent on a sufficent level of usage from
rust superseding the current Python space usage in the core of Qiskit.
* Add num_nonlocal_gates implementation in rust
This commit adds a native rust implementation to rust for the
num_nonlocal_gates method on QuantumCircuit. Now that we have a rust
representation of gates it is potentially faster to do the count because
the iteration and filtering is done rust side.
* Performance tuning circuit construction
This commit fixes some performance issues with the addition of standard
gates to a circuit. To workaround potential reference cycles in Python
when calling rust we need to check the parameters of the operation. This
was causing our fast path for standard gates to access the `operation`
attribute to get the parameters. This causes the gate to be eagerly
constructed on the getter. However, the reference cycle case can only
happen in situations without a standard gate, and the fast path for
adding standard gates directly won't need to run this so a skip is added
if we're adding a standard gate.
* Add back validation of parameters on gate methods
In the previous commit a side effect of the accidental eager operation
creation was that the parameter input for gates were being validated by
that. By fixing that in the previous commit the validation of input
parameters on the circuit methods was broken. This commit fixes that
oversight and adds back the validation.
* Skip validation on gate creation from rust
* Offload operation copying to rust
This commit fixes a performance regression in the
`QuantumCircuit.copy()` method which was previously using Python to copy
the operations which had extra overhead to go from rust to python and
vice versa. This moves that logic to exist in rust and improve the copy
performance.
* Fix lint
* Perform deepcopy in rust
This commit moves the deepcopy handling to occur solely in Rust.
Previously each instruction would be directly deepcopied by iterating
over the circuit data. However, we can do this rust side now and doing
this is more efficient because while we need to rely on Python to run a
deepcopy we can skip it for the Rust standard gates and rely on Rust to
copy those gates.
* Fix QuantumCircuit.compose() performance regression
This commit fixes a performance regression in the compose() method. This
was caused by the checking for classical conditions in the method
requiring eagerly converting all standard gates to a Python object. This
changes the logic to do this only if we know we have a condition (which
we can determine Python side now).
* Fix map_ops test case with no caching case
* Fix typos in docs
This commit fixes several docs typos that were caught during code review.
Co-authored-by: Eli Arbel <46826214+eliarbel@users.noreply.github.com>
* Shrink memory usage for extra mutable instruction state
This commit changes how we store the extra mutable instruction state
(condition, duration, unit, and label) for each `CircuitInstruction`
and `PackedInstruction` in the circuit. Previously it was all stored
as separate `Option<T>` fields on the struct, which required at least
a pointer's width for each field which was wasted space the majority of
the time as using these fields are not common. To optimize the memory
layout of the struct this moves these attributes to a new struct which
is put in an `Option<Box<_>>` which reduces it from 4 pointer widths
down to 1 per object. This comes from extra runtime cost from the extra
layer of pointer indirection but as this is the uncommon path this
tradeoff is fine.
* Remove Option<> from params field in CircuitInstruction
This commit removes the Option<> from the params field in
CircuitInstruction. There is no real distinction between an empty vec
and None in this case, so the option just added another layer in the API
that we didn't need to deal with. Also depending on the memory alignment
using an Option<T> might have ended up in a little extra memory usage
too, so removing it removes that potential source of overhead.
* Eagerly construct rust python wrappers in .append()
This commit updates the Python code in QuantumCircuit.append() method
to eagerly construct the rust wrapper objects for python defined circuit
operations.
* Simplify code around handling python errors in rust
* Revert "Skip validation on gate creation from rust"
This reverts commit 2f81bde8bf. The
validation skipping was unsound in some cases and could lead to invalid
circuit being generated. If we end up needing this as an optimization we
can remove this in the future in a follow-up PR that explores this in
isolation.
* Temporarily use git for qasm3 import
In Qiskit/qiskit-qasm3-import#34 the issue we're hitting caused by
qiskit-qasm3-import using the private circuit attributes removed in this
PR was fixed. This commit temporarily moves to installing it from git so
we can fully run CI. When qiskit-qasm3-import is released we should
revert this commit.
* Fix lint
* Fix lint for real (we really need to use a py312 compatible version of pylint)
* Fix test failure caused by incorrect lint fix
* Relax trait-method typing requirements
* Encapsulate `GILOnceCell` initialisers to local logic
* Simplify Interface for building circuit of standard gates in rust
* Simplify complex64 creation in gate_matrix.rs
This just switches Complex64::new(re, im) to be c64(re, im) to reduce
the amount of typing. c64 needs to be defined inplace so it can be a
const fn.
* Simplify initialization of array of elements that are not Copy (#28)
* Simplify initialization of array of elements that are not Copy
* Only generate array when necessary
* Fix doc typos
Co-authored-by: Kevin Hartman <kevin@hart.mn>
* Add conversion trait for OperationType -> OperationInput and simplify CircuitInstruction::replace()
* Use destructuring for operation_type_to_py extra attr handling
* Simplify trait bounds for map_indices()
The map_indices() method previously specified both Iterator and
ExactSizeIterator for it's trait bounds, but Iterator is a supertrait of
ExactSizeIterator and we don't need to explicitly list both. This commit
removes the duplicate trait bound.
* Make Qubit and Clbit newtype member public
As we start to use Qubit and Clbit for creating circuits from accelerate
and other crates in the Qiskit workspace we need to be able to create
instances of them. However, the newtype member BitType was not public
which prevented creating new Qubits. This commit fixes this by making it
public.
* Use snakecase for gate matrix names
* Remove pointless underscore prefix
* Use downcast instead of bound
* Rwork _append reference cycle handling
This commit reworks the multiple borrow handling in the _append() method
to leveraging `Bound.try_borrow()` to return a consistent error message
if we're unable to borrow a CircuitInstruction in the rust code meaning
there is a cyclical reference in the code. Previously we tried to detect
this cycle up-front which added significant overhead for a corner case.
* Make CircuitData.global_phase_param_index a class attr
* Use &[Param] instead of &SmallVec<..> for operation_type_and_data_to_py
* Have get_params_unsorted return a set
* Use lookup table for static property methods of StandardGate
* Use PyTuple::empty_bound()
* Fix lint
* Add missing test method docstring
* Reuse allocations in parameter table update
* Remove unnecessary global phase zeroing
* Move manually set params to a separate function
* Fix release note typo
* Use constant for global-phase index
* Switch requirement to release version
---------
Co-authored-by: Eli Arbel <46826214+eliarbel@users.noreply.github.com>
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
Co-authored-by: John Lapeyre <jlapeyre@users.noreply.github.com>
Co-authored-by: Kevin Hartman <kevin@hart.mn>
* Bump faer from 0.18.2 to 0.19.0
Bumps [faer](https://github.com/sarah-ek/faer-rs) from 0.18.2 to 0.19.0.
- [Changelog](https://github.com/sarah-ek/faer-rs/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sarah-ek/faer-rs/commits)
---
updated-dependencies:
- dependency-name: faer
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
* Bump faer-ext to 0.2.0 too
The faer and faer-ext versions need to be kept in sync. This commit
bumps the faer-ext version as part of the dependabot automated bump for
faer to do this.
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Now that the first release candidate for the 1.1.0 release has been
tagged, the stable branch for the 1.1 series has been created and we
can start developing the 1.1.0 release on main. This commit bumps all
the version strings from 1.1.0 to 1.2.0 (and the backport branch for
mergify to stable/1.1) accordingly to differentiate the main branch
from 1.1.*.
* Adapt crates/qasm3 to work with recent versions of openqasm3_parser
This commit adds no new features or capabilities to the importer. But it brings
the importer up to date with the latest version of openqasm3_parser as a preliminary
step in improving the importer.
The biggest change in openqasm3_parser is in handling stdgates.inc. Upon encountering
`include "stdgates.inc" openqasm3_parser reads no file, but rather adds symbols to the
symbol table for gates in the standard library.
The function `convert_asg` in the importer calls oq3_semantics:🔣:SymbolTable.gates
which returns a `Vec` of information about each "declared" gate. The information is the
gate's name and signature and SymbolID, which is sufficient to do everything the importer
could do before this commit.
Encountering `Stmt::GateDefinition` now is a no-op rather than an error. (This was
previously called `Stmt::GateDeclaration`, but importantly it is really a definition.)
How the standard library, and gates in general, are handled will continue to evolve.
A behavioral difference between this commit and its parent: Before if the importer
encountered a gate call before the corresponding definition an error would be raised. With
the current commit, the importer behaves as if all gate definitions were moved to the top
of the OQ3 program. However, the error will still be found by the parser so that the
importer never will begin processing statements.
The importer depends on a particular branch of a copy of openqasm3_parser. When
the commit is ready to merge, we will release a version of openqasm3_parser and
depend instead on that release.
See https://github.com/openqasm/openqasm/pull/517
* Remove unnecessary conversion `name.to_string()`
Response to reviewer comment https://github.com/Qiskit/qiskit/pull/12087/files#r1586949717
* Remove check for U gate in map_gate_ids
* This requires modifying the external parser crate.
* Depend temporarily on the branch of the parser with this modification.
* Make another change required by other upstream improvments.
* Cargo config files are changed because of above changes.
* Return error returned by map_gate_ids in convert_asg
Previously this error was ignored. This would almost certainly cause
an error later. But better to do it at the correct place.
* Remove superfluous call to `iter()`
* Depend on published oq3_semantics 0.6.0
* Fix cargo lock file
---------
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
* Oxidize the numeric code in the Isometry gate class
This commit ports the numeric portion of the Isometry gate class to
rust. While this will likely improve the performance slightly this move
is more to make isolate this code from blas/lapack in numpy. We're
hitting some stability issues on arm64 mac in CI and moving this code to
rust should hopefully fix this issue. As this is more for functional
reasons no real performance tuning was done on this port, there are
likely several opportunities to improve the runtime performance of the
code.
* Remove unused import
* Use rust impl for small utility functions too
* Oxidize the linalg in UCGate too
The UCGate class is used almost exclusively by the Isometry class to
build up the definition of the isometry circuit. There were also some
linear algebra inside the function which could also be the source of the
stability issues we were seeing on arm64. This commit ports this
function as part of the larger isometry migration.
* Migrate another numeric helper method of UCGate
* Remove now unused code paths
* Remove bitstring usage with bitwise ops
This commit removes the use of bit string manipulations that were
faithfully ported from the original python logic (but left a bad taste
in my mouth) into more efficient bitwise operations (which were
possible in the original python too).
* Mostly replace Vec<u8> usage with bitwise operations
The use of intermediate Vec<u8> as proxy bitstrings was originally
ported nearly exactly from the python implementation. But since
everything is working now this commit switches to use bitwise operations
where it makes sense as this will be more efficient.
* Apply suggestions from code review
Co-authored-by: Jake Lishman <jake@binhbar.com>
* Remove python side call sites
* Fix integer typing in uc_gate.rs
* Simplify basis state bitshift loop logic
* Build set of control labels outside construct_basis_states
* Use 2 element array for reverse_qubit_state
* Micro optimize reverse_qubit_state
* Use 1d numpy arrays for diagonal inputs
* Fix lint
* Update crates/accelerate/src/isometry.rs
Co-authored-by: John Lapeyre <jlapeyre@users.noreply.github.com>
* Add back sqrt() accidentally removed by inline suggestion
* Use a constant for rz pi/2 elements
---------
Co-authored-by: Jake Lishman <jake@binhbar.com>
Co-authored-by: John Lapeyre <jlapeyre@users.noreply.github.com>
* Refactor Rust crates to build a single extension module
Previously we were building three different Python extension modules out
of Rust space. This was convenient for logical separation of the code,
and for making the incremental compilations of the smaller crates
faster, but had the disadvantage that `qasm2` and `qasm3` couldn't
access the new circuit data structures directly from Rust space and had
to go via Python.
This modifies the crate structure to put the Rust-space acceleration
logic into crates that we only build as Rust libraries, then adds
another (`pyext`) crate to be the only that that actually builds as
shared Python C extension. This then lets the Rust crates interact with
each other (and the Rust crates still contain PyO3 Python-binding logic
internally) and accept and output each others' Python types.
The one Python extension is still called `qiskit._accelerate`, but it's
built by the Rust crate `qiskit-pyext`. This necessitated some further
changes, since `qiskit._accelerate` now contains acccelerators for lots
of parts of the Qiskit package hierarchy, but needs to have a single
low-level place to initialise itself:
- The circuit logic `circuit` is separated out into its own separate
crate so that this can form the lowest part of the Rust hierarchy.
This is done so that `accelerate` with its grab-bag of accelerators
from all over the place does not need to be the lowest part of the
stack. Over time, it's likely that everything will start touching
`circuit` anyway.
- `qiskit._qasm2` and `qiskit._qasm3` respectively became
`qiskit._accelerate.qasm2` and `qiskit._accelerate.qasm3`, since they
no longer get their own extension modules.
- `qasm3` no longer stores a Python object on itself during module
initialisation that depended on `qiskit.circuit.library` to create.
Now, the Python-space `qiskit.qasm3` does that and the `qasm3` crate
just retrieves that at Python runtime, since that crate requires
Qiskit to be importable anyway.
* Fix and document Rust test harness
* Fix new clippy complaints
These don't appear to be new from this patch series, but changing the
access modifiers on some of the crates seems to make clippy complain
more vociferously about some things.
* Fix pylint import order
* Remove erroneous comment
* Fix typos
Co-authored-by: Kevin Hartman <kevin@hart.mn>
* Comment on `extension-module`
* Unify naming of `qiskit-pyext`
* Remove out-of-date advice on starting new crates
---------
Co-authored-by: Kevin Hartman <kevin@hart.mn>
This commit bumps the faer version used to the latest release 0.18.x.
There were some changes to the package structure in 0.18 which reduced
the number of crates used to build faer as it's now a flatter project.
However, the converter to ndarray is now in a seperate faer-ext crate
which is added to the dependencies list.
* Oxidize TwoQubitWeylDecomposition
This commit is part 1 of migrating the default 2q unitary synthesis to leverage
parallel rust described in #8774, the eventual goal is to be able to
run unitary synthesis in parallel for all the unitary matrices in a
circuit in a single call from the `UnitarySynthesis` pass. This commit
lays the initial groundwork for doing this by starting with the largest
piece of the default 2q unitary synthesis code, the
TwoQubitWeylDecomposition class. It migrates the entire class
to be a pyclass in rust. There is still a Python subclass for it that
handles the actual QuantumCircuit generation and also the string
representations which are dependent on circuit generation. The goal of
this is to keep the same basic algorithm in place but re-implement
as-is in Rust as a common starting point for eventual improvements to
the underlying algorithm as well as parallelizing the synthesis of
multiple 2q unitary matrices.
* Fix typo in closest_partial_swap()
This commit fixes a typo the formula in the function.
This is the same fix from #11953.
Co-authored-by: Shelly Garion <46566946+ShellyGarion@users.noreply.github.com>
* Run black and lint
* Fix potential imaginary component sign flip in determinant
* Run cargo fmt
* Simplify using numpy eigh example comment
* Add missing checks to decompose_two_qubit_product_gate()
* Use rng first trial from Python implementation
To aid in debugging and rule out rng differences causing different
results this commit switches the first iteration of the randomized loop
to have hard coded values that are identical to what the rng in numpy
was returning. It is very unlikely that this will have any impact
because the specific random numbers used shouldn't matter, this is
mostly to just rule it out as a possibility in debugging the remaining
test failures.
* Fix whitespace in error message
* Fix assert check
* Fix missing multiplier on specialized weyl gate
* Fix various mistakes
This commit fixes two fundamental issues in the code. The first is the
rz and ry matrix were being incorrectly constructed for a given angle.
This caused the specializations that were computing the 1q matrices in
the decomposition based on a product with these gates' matrices to
return invalid results. The second issue is for the MirrorControlledEquiv
specialization had the angles backwards for computing the matrix of the
rz gates used in the products for the 1q matrices:
`K1l = K1l @ Rz(K1r)` and `K1r = K1r @ Rz(K1l)` not
`K1l = K1l @ Rz(K1l)` and `K1r = K1r @ Rz(K1r)`
This was a typo from the original transcription.
* Add pickle serialization support for TwoQubitWeylDecomposition
* Remove duplicate conjs increment
* Fix fSim abmb equivalent specialization
* Add specialized test class back
* Use QiskitError for backwards compatibility
* Add release note
* Make explicit specialization private
* Use explicit inheritance from general decomposition (#23)
* Apply suggestions from code review
* Use smallvec for circuit sequence params and qubits
* Use const 2x2 identity array where possible
* circuit() and weyl_gate don't need a mutable self
* Remove unnecessary inline annotations
* Rename Specializations enum Specialization
* Add back specialize() method and deprecate
* Reorganize Python/Rust split to wrap rust instead of subclass
This commit reworks the handoff between python and rust space for the
TwoQubitWeylDecomposition class. Previously the Python side
TwoQubitWeylDecomposition was a subclass of the Rust struct/pyclass of
the same name. This was originally done to deduplicate the the getters
for the attributes. However, because of the overhead associated with
some of the rust getters and needing to do some import normalization to
a numpy array the deduplication wasn't worth the cost.
* Remove unecessary allocations
* Rename DEFAULT_ATOL to ANGLE_ZERO_EPSILON
* Stop obsessing over -0
* Handle enum to int conversion as method
* Cleanup decompose_two_qubit_product_gate()
* Use a trait for trace_to_fid()
* Use an enum instead of string for euler basis
* Fix release note typo
* Improve magic basis transformation functions
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
* Remove eigh() util function
* Revert unecessary changes to callers of TwoQubitWeylDecomposition
* Restore debug logging and add test assertions for it
* Update qiskit/synthesis/two_qubit/two_qubit_decompose.py
Co-authored-by: Lev Bishop <18673315+levbishop@users.noreply.github.com>
* Add specialization to __str__
* Add previous specialized class docstrings as inline rust code comments
* Rename fSim variants and suprress rustc warning about camel case
* Update tests for correct specialization enum name
* Expose specialization enum via private class attr and use for __repr__
---------
Co-authored-by: Shelly Garion <46566946+ShellyGarion@users.noreply.github.com>
Co-authored-by: Jake Lishman <jake@binhbar.com>
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
Co-authored-by: Lev Bishop <18673315+levbishop@users.noreply.github.com>
This commit updates the fast_sum() function to improve the runtime for
rust functions that are computing the sum of an array of f64s. This is
done by leveraging runtime simd dispatch via the pulp library[1]. The
pulp library is already a dependency as it's getting pulled in from
faer/faer-core. This commit just makes it an direct dependency of qiskit
and we use it directly to compute the sums inside fast sum. This commit
also updates the faer version so that we're keeping pulp and faer on the
latest versions explicitly.
Now that the first release candidate for the 1.0.0 release has been
tagged, the stable branch for the 1.0 series has been created and we
can start developing the 1.1.0 release on main. This commit bumps all
the version strings from 1.0.0 to 1.1.0 (and the backport branch for
mergify to 1.0) accordingly to differentiate the main branch from
1.0.*.
dependabot[bot]