Prepare `PauliEvolutionGate` for Rustiq & port it to Rust by Cryoris · Pull Request #13295 · Qiskit/qiskit

Cryoris · 2024-10-08T12:13:23Z

Summary

Port the PauliEvolutionGate synthesis to Rust, plus, expose the Pauli network and allow other plugins to synthesize the gate. Also adds the plugin structure for the gate for #12789.

Details and comments

The larger the Pauli network to synthesis, the better the speedup from the port to Rust. Here I measured a Heisenberg Hamiltonian (XX+YY+ZZ on interacting qubits, plus 1-qubit Z on each qubit) on a square lattice for different settings:

1 timestep for first order Trotter: speedup @ 100 qubits is 2.8

N=25: 7.0
main: 0.007 +- 0.006
this: 0.001 +- 0.000

N=100: 2.8
main: 0.042 +- 0.000
this: 0.015 +- 0.000

N=255: 2.8
main: 0.198 +- 0.040
this: 0.071 +- 0.003

N=400: 2.3
main: 0.607 +- 0.001
this: 0.260 +- 0.000

10 timestep for 4th order Trotter: speedup @ 100 qubits is 9.4

N=25: 6.7
main: 0.040 +- 0.003
this: 0.006 +- 0.000

N=100: 9.4
main: 0.330 +- 0.037
this: 0.035 +- 0.001

N=255: 10.8
main: 1.291 +- 0.066
this: 0.119 +- 0.007

N=400: 11.5
main: 4.052 +- 0.051
this: 0.353 +- 0.009

1 timestep for first order Trotter but with wrap=True: speedup @ 100 qubits is 3.6

N=25: 3.4
main: 0.034 +- 0.012
this: 0.010 +- 0.004

N=100: 3.6
main: 0.187 +- 0.017
this: 0.052 +- 0.010

N=255: 3.1
main: 0.551 +- 0.048
this: 0.178 +- 0.019

N=400: 3.0
main: 1.367 +- 0.068
this: 0.458 +- 0.027

Side effects of this PR:

add SparsePauliOp.to_sparse_list to construct the sparse list format (i.e. op == SparsePauliOp.from_sparse_list(op.to_sparse_list()))
refactor LieTrotter to just be an alias of SuzukiTrotter and reduce code duplication
fix the docstrings to use actually non-commuting Paulis (XX and ZZ commute and would have no expansion error)

coveralls · 2024-10-08T12:39:10Z

Pull Request Test Coverage Report for Build 11667384085

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

313 of 332 (94.28%) changed or added relevant lines in 12 files are covered.
587 unchanged lines in 28 files lost coverage.
Overall coverage increased (+0.03%) to 88.756%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/circuit/src/operations.rs	1	2	50.0%
qiskit/synthesis/evolution/suzuki_trotter.py	18	20	90.0%
qiskit/synthesis/evolution/product_formula.py	41	45	91.11%
qiskit/synthesis/evolution/qdrift.py	14	18	77.78%
crates/accelerate/src/circuit_library/pauli_evolution.rs	204	212	96.23%

Files with Coverage Reduction	New Missed Lines	%
qiskit/transpiler/target.py	1	93.84%
qiskit/circuit/library/boolean_logic/quantum_or.py	1	98.08%
crates/accelerate/src/basis/basis_translator/basis_search.rs	1	99.31%
qiskit/circuit/library/boolean_logic/quantum_and.py	1	97.96%
qiskit/circuit/library/boolean_logic/inner_product.py	1	96.0%
qiskit/circuit/store.py	1	97.06%
qiskit/qasm2/export.py	1	98.48%
crates/accelerate/src/split_2q_unitaries.rs	2	96.43%
qiskit/transpiler/passmanager_config.py	3	96.1%
crates/accelerate/src/basis/basis_translator/compose_transforms.rs	3	97.48%

Totals
Change from base Build 11601286937:	0.03%
Covered Lines:	76579
Relevant Lines:	86280

💛 - Coveralls

--> expand should return float | ParameterExpression

some things are still upside down and it seems like it would be cleaner to do the time multiplication inside pauli_evolution

qiskit-bot · 2024-10-15T11:49:58Z

One or more of the following people are relevant to this code:

@Cryoris
@Qiskit/terra-core
@ajavadia

raynelfss

I quickly reviewed the rust code. Great job. There are some questions I have that I'm fully open to discussing.

raynelfss · 2024-10-23T14:35:11Z

+    time: Param,
+    phase_gate: bool,
+    do_fountain: bool,
+) -> Box<dyn Iterator<Item = StandardInstruction> + 'a> {


Why are we using a Box here? From what I understand, using a Box pointer can save memory by storing things in the heap rather than the stack. But is it that much more expensive than just returning a regular iterator? Standard gates aren't supposed to be too heavy either.

This isn't critical as performance wouldn't be impacted from what I can tell since StandardGate instances are very light. When it comes to Param instances, it might be a bit trickier. But it is something to think about.

This is because this function returns different types of Iterator depending on the input (e.g. Chain<Map<...>> vs Empty). The dynamic type was the only way I got to work, but I'm happy to change it if there's a better way 🙂

From a recent talk I had with @alexanderivrii it seems that you want to call the .rev method to be able to reverse the iterator. If so, perhaps you could change the return types to be DoubleEndedIterator instances instead of a Box<dyn Iterator<_>>.

So you could change some of the return types from:

pub fn foo() -> Box<dyn Iterator<Item = StandardInstruction> + 'a> {

to:

pub fn foo() -> impl DoubleEndedIterator<Item = StandardInstruction> + 'a {

This would allow you to use any iterator type as long as it can be reversed, which seems to be the case for many of the iterators used here.

raynelfss · 2024-10-23T14:58:04Z

+        .clone()
+        .into_iter()


For this I think you might need to rewrite the logic quite a bit to avoid some cloning, since you're cloning the iterator's source each time. Maybe start by using iter().copied() here since both structures implement the Copy trait.
You might also be better off collecting some of them instead of cloning the source. At least for this one I think you could get away with collecting, and maybe the inverse_basis_change as well since you will re-append. Then you can call into-iter() at the end to consume them.

raynelfss · 2024-10-23T16:52:09Z

+/// Get an iterator that returns a barrier or an empty element.
+pub fn maybe_barrier(
+    py: Python,
+    num_qubits: u32,
+    insert_barriers: bool,
+) -> Box<dyn Iterator<Item = PyResult<Instruction>>> {
+    // TODO could speed this up by only defining the barrier class once
+    if !insert_barriers {
+        Box::new(std::iter::empty())
+    } else {
+        let barrier_cls = imports::BARRIER.get_bound(py);
+        let barrier = barrier_cls
+            .call1((num_qubits,))
+            .expect("Could not create Barrier Python-side");
+        let barrier_inst = PyInstruction {
+            qubits: num_qubits,
+            clbits: 0,
+            params: 0,
+            op_name: "barrier".to_string(),
+            control_flow: false,
+            instruction: barrier.into(),
+        };
+        Box::new(std::iter::once(Ok((
+            barrier_inst.into(),
+            smallvec![],
+            (0..num_qubits).map(Qubit).collect(),
+            vec![] as Vec<Clbit>,
+        ))))
+    }
+}


This method is a little confusing:

From what I can gather it returns a Barrier as an Instruction but then it returns a Box<Iterator<_>> instance, even though it is one item. Is this a memory saving measure?

If the purpose of this operation is to just return a Barrier if a condition is met, you should probably have this labeled as #[inline] since it's only a conditional check. This prevents the compiler from seeing an extra call to this function.

Going back to @alexanderivrii's comment, could you maybe use insert_barrier.then_some().

I changed to then_some in cf7d8b0 but I think this has one disadvantage: when we write something like

instructions.chain( insert_barrier.then_some(Ok(barrier.clone()) )

Then even if insert_barrier is false, I need to make the Python call to construct the barrier object. To avoid that, what I would like to do is

let barrier = match insert_barrier { true => Some(.... get barrier instruction...), false => None, } // in my iteration loop ... instructions.chain( insert_barrier.then_some(Ok(barrier.clone().unwrap())) )

but rust won't allow this since barrier can be None and I'm not allowed to unwrap 🤔

So it seems we have a performance vs. code legibility issue here, which is why I had the maybe_barrier function. How about making this into a struct with some documentation? Like

struct MaybeBarrier { barrier: Option<Instruction> } impl MaybeBarrier { fn from_py(...) // construct the barrier object fn get(condition) // return None or the barrier based on the condition }

alexanderivrii · 2024-10-31T15:54:00Z

Hmm, after switching SX and SXdg in 2b6f4eb, some of the tests in pauli_feature_map now fail. I believe the tests were incorrect before 2b6f4eb, so it's good that they would be fixed, yet it's scary how difficult it is to distinguish between the correct and incorrect behaviors (I was actually looking at these before and they looked perfectly fine to me). Can we add more Operator-based asserts? I.e. in addition to checking that the ref circuit looks as it's supposed to, also that Operator(encoding) == Operator(ref)?

Other than that, I am very happy with this PR, thanks for the great work!

raynelfss

I had a bit of a discussion with @alexanderivrii about the usage of Box here, and we believe to have found a better alternative to what's being done here. I haven't tested it myself but it might be worth taking a look.

raynelfss · 2024-10-31T15:46:16Z

+    time: Param,
+    phase_gate: bool,
+    do_fountain: bool,
+) -> Box<dyn Iterator<Item = StandardInstruction> + 'a> {


From a recent talk I had with @alexanderivrii it seems that you want to call the .rev method to be able to reverse the iterator. If so, perhaps you could change the return types to be DoubleEndedIterator instances instead of a Box<dyn Iterator<_>>.

So you could change some of the return types from:

pub fn foo() -> Box<dyn Iterator<Item = StandardInstruction> + 'a> {

to:

pub fn foo() -> impl DoubleEndedIterator<Item = StandardInstruction> + 'a {

This would allow you to use any iterator type as long as it can be reversed, which seems to be the case for many of the iterators used here.

alexanderivrii · 2024-10-31T16:08:28Z

For the record, I am no longer sure what was our conclusion with @raynelfss (Ray is so ahead of me when discussing Rust types). I know that @Cryoris used boxing to be able to return both the usual and the double-ended iterators (and maybe something else too), yet if I remember correctly the double-ended iterators are a bit heavier than the usual ones. Does it make sense for us to return the double-ended iterators everywhere? Another possibility is maybe we should return the CircuitData objects (instead of Vec<Instruction> or iterator over that).

raynelfss · 2024-10-31T18:59:18Z

In hindsight @Cryoris, we might not be able to use a simple impl Trait I believe I can now see why you used so many Box pointers.

This is because this function returns different types of Iterator depending on the input (e.g. Chain<Map<...>> vs Empty). The dynamic type was the only way I got to work, but I'm happy to change it if there's a better way 🙂

Even though both Once iterators and an example iterator such as Chain<Map<Iterator>> should technically both count as Iterator the types are different enough to require a dynamic block, and so you'd need to use the Box there. I can't think of another way to do this right now, so you can keep the Box here.

ShellyGarion

LGTM. I only have a few comments and questions.

ShellyGarion · 2024-11-04T11:51:05Z

+
+// custom types for a more readable code
+type StandardInstruction = (StandardGate, SmallVec<[Param; 3]>, SmallVec<[Qubit; 2]>);
+type Instruction = (


Perhaps the name "Instruction" can be confusing with Qiskit Instruction? Maybe call it something like "EvolutionIstruction" ?

This typedef represents a packed instruction, which can be used as input to CircuitData.from_packed_instructions (so it's not specific to an evolution). The same is used in some other places (e.g. quantum volume or pauli feature map), so I'd prefer keeping as is for now and potentially adding a general typedef used across all of the rust code 🙂

ShellyGarion · 2024-11-04T12:18:57Z

    def __init__(
        self,
-        operator,
-        time: Union[int, float, ParameterExpression] = 1.0,


why is ParamterExpression replaced by ParameterValueType ? (isn't this considered as an API change) ?

It's the same, ParameterValueType is a typedef used across the circuit and the gates, it's defined as

ParameterValueType = Union[ParameterExpression, float]

(see the quantumcircuit.py file)

alexanderivrii

Thanks @Cryoris! Let me approve the PR, but let's also give a chance to @ShellyGarion and @raynelfss to see if they have additional comments.

raynelfss

Taking all previous discussions into consideration, this LGTM!

* py version for expand * starting to write some code * implementing * cleanup * cleanup * expand fully & simplify lie trotter * use examples that actually do not commute * add plugin structure * fixing global phase for all-I rotations * fixes * fixing plugin names * minor * removing a random print statement * additional improvements * improving rustiq plugin * merge with #13239 * Adding pauli evolution plugins to docstrings * adding documentation on rustiq plugin * fixes after refactoring * typo * more merges with #13295; adding more Rustiq tests * more efficient append_sx and append_sxdg gates for cliffords * review comments * moving the pauli network synthesis logic into a separate file * some code review suggestions * simplifying the code by merging the oredered and unorderd version of rotation injection * more review comments * adding python tests * more code review suggestions * more review comments * more review comments * test for preserve_order * lint * upgrading rustiq-core to 0.0.10 * clippy: removing mutable ref * Improving PauliEvolution synthesis tests. Making sure that the number of rotation gates in the synthesized circuit equals the number of non-trivial Pauli rotation gates. * documentation fixes after the merge --------- Co-authored-by: Julien Gacon <jules.gacon@googlemail.com>

Cryoris added 5 commits October 3, 2024 16:11

py version for expand

3a15589

Merge branch 'main' into paulievo

cea830b

expand fully & simplify lie trotter

72f2689

use examples that actually do not commute

8cd2c25

add plugin structure

681105d

alexanderivrii reviewed Oct 9, 2024

View reviewed changes

Comment thread qiskit/synthesis/evolution/product_formula.py Outdated

alexanderivrii mentioned this pull request Oct 9, 2024

Add Rustiq-based synthesis for PauliEvolutionGate #13301

Merged

2 tasks

fix plugin name, rm complex from expand

58e4a03

--> expand should return float | ParameterExpression

Cryoris mentioned this pull request Oct 11, 2024

Fix QuantumCircuit.decompose for high-level objects #13311

Merged

Cryoris added 9 commits October 11, 2024 16:11

paulievo in Rust

7f2ec3d

take care of global phase

f9b72cf

support barriers

3985394

fix time parameter

99a1153

some things are still upside down and it seems like it would be cleaner to do the time multiplication inside pauli_evolution

fix lint

214b969

Merge branch 'paulievo' into rust/paulievo

d96cebf

fix final barrier

e8bcc4f

fix wrapping

aba92e2

add reno and HLS docs

4fcf639

Cryoris changed the title ~~Prepare PauliEvolutionGate plugin structure & rustiq integration~~ Prepare PauliEvolutionGate for Rustiq & port it to Rust Oct 15, 2024

Cryoris added 2 commits October 15, 2024 13:41

Merge branch 'main' into paulievo

b53b332

fix unreachable

5c95b0d

Cryoris marked this pull request as ready for review October 15, 2024 11:49

Cryoris requested review from a team and ShellyGarion as code owners October 15, 2024 11:49

fix QPY test & pauli feature map

2eb66f1

raynelfss linked an issue Oct 15, 2024 that may be closed by this pull request

Add PauliEvolutionGate synthesis plugin using rustiq #12789

Closed

raynelfss added this to the 1.3.0 milestone Oct 15, 2024

use SX as basis tranfo

87496d2

raynelfss reviewed Oct 23, 2024

View reviewed changes

Cryoris added 3 commits October 28, 2024 13:23

implement review comments

cf7d8b0

do_fountain

6f4fcba

clippy

6217d0e

raynelfss assigned alexanderivrii and raynelfss Oct 29, 2024

Merge branch 'main' into paulievo

b79751d

alexanderivrii reviewed Oct 31, 2024

View reviewed changes

Comment thread test/python/circuit/library/test_pauli_feature_map.py Outdated

alexanderivrii reviewed Oct 31, 2024

View reviewed changes

Comment thread qiskit/synthesis/evolution/product_formula.py

alexanderivrii reviewed Oct 31, 2024

View reviewed changes

Comment thread qiskit/synthesis/evolution/suzuki_trotter.py Outdated

Cryoris added 3 commits October 31, 2024 13:38

review comments

e802c45

Merge branch 'paulievo' of github.com:Cryoris/qiskit-terra into paulievo

9b7b0c8

fix the basis trafo!

2b6f4eb

alexanderivrii added a commit to alexanderivrii/qiskit-terra that referenced this pull request Oct 31, 2024

more merges with Qiskit#13295; adding more Rustiq tests

be7a1a3

raynelfss reviewed Oct 31, 2024

View reviewed changes

properly test the evolution basis changes

1af569b

ShellyGarion reviewed Nov 4, 2024

View reviewed changes

Cryoris added 2 commits November 4, 2024 13:50

fix more tests

c478cc1

Shelly's review comments

8d5e3f3

alexanderivrii approved these changes Nov 4, 2024

View reviewed changes

raynelfss approved these changes Nov 4, 2024

View reviewed changes

raynelfss added this pull request to the merge queue Nov 4, 2024

Merged via the queue into Qiskit:main with commit db04339 Nov 4, 2024

Cryoris deleted the paulievo branch November 4, 2024 21:07

ShellyGarion added the Changelog: Added Add an "Added" entry in the GitHub Release changelog. label Nov 5, 2024

Conversation

Cryoris commented Oct 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details and comments

Uh oh!

coveralls commented Oct 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Test Coverage Report for Build 11667384085

Warning: This coverage report may be inaccurate.

Details

💛 - Coveralls

Uh oh!

Uh oh!

qiskit-bot commented Oct 15, 2024

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

raynelfss Oct 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cryoris Oct 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexanderivrii commented Oct 31, 2024

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexanderivrii commented Oct 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

raynelfss commented Oct 31, 2024

Uh oh!

ShellyGarion left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexanderivrii left a comment

Choose a reason for hiding this comment

Uh oh!

raynelfss left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Cryoris commented Oct 8, 2024 •

edited

Loading

coveralls commented Oct 8, 2024 •

edited

Loading

raynelfss Oct 23, 2024 •

edited

Loading

Cryoris Oct 28, 2024 •

edited

Loading

alexanderivrii commented Oct 31, 2024 •

edited

Loading