Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior with default compilation set #302

Open
bachase opened this issue Mar 12, 2025 · 2 comments
Open

Unexpected behavior with default compilation set #302

bachase opened this issue Mar 12, 2025 · 2 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@bachase
Copy link
Collaborator

bachase commented Mar 12, 2025

Describe the bug
While reviewing unitaryfund/ucc-demo#1, @jordandsullivan noticed that a simple Bell state circuit was transforming the circuit even though it was already in the target gate basis:

Image

Debugging a bit, this appears to be due to forcing consolidation of blocks, after which unitary synthesis expands to the different gateset:

self.pass_manager.append(ConsolidateBlocks(force_consolidate=True))

To Reproduce
Steps to reproduce the behavior:

  1. Run the circuit in the unit tests
    circuit = QiskitCircuit(2)
    circuit.h(0)
    circuit.cx(0, 1)
    result_circuit = compile(circuit, return_format="original")

To debug, I edited UCCDefault1.run to print the circuit after each pass:

def callback_func(**kwargs):
    from qiskit.converters import dag_to_circuit

    pass_ = kwargs["pass_"]
    dag = kwargs["dag"]
    print(f"Pass: {pass_.name()}")
    print(dag_to_circuit(dag))
    print("-" * 80)

class UCCDefault1:
....
   def run(self, circuits):
       return self.pass_manager.run(circuits, callback=callback_func)

Expected behavior
We would expect the circuit to stay the same.

@bachase bachase added the bug Something isn't working label Mar 12, 2025
@bachase
Copy link
Collaborator Author

bachase commented Mar 12, 2025

@jordandsullivan and @Misty-W , removing the force_consolidate gives the expected result, but I'm wondering what the original reason was behind setting that to True in the first place. Do either of you know? I'll make a branch with that change and run the benchmarks to see the impact.

On the flip side, there's an interesting question of why the compiler didn't re-optimize back to the simpler circuit after that pass, versus the more complex one it ended up with.

But stepping back, for the next milestone, it might be worth revisiting these choice of default passes, and ensuring we capture somewhere the reasons, or at least types of circuits, where they perform well.

@bachase
Copy link
Collaborator Author

bachase commented Mar 12, 2025

ef0e5c9 has the benchmark results.

Pulling out the gate counts -

compiler circuit_name raw_multiq_gates ucc baseline(force consolidate) ucc_dont_force_consolidate qiskit-default
ucc qaoa_barabasi_albert 1176 1176 1176 1176
ucc qft 10050 2740 3244 3244
ucc qv 15000 14856 14856 14856
ucc square_heisenberg 2160 540 540 540
ucc prep_select 9744 9702 9710 9708
ucc qcnn 388 388 388 388

So qft gate count is definitely worse without the consolidation. I added qiskit-default as a baseline, as it shows that ucc without the consolidation is the same gate count reduction for qft as qiskit (ignoring compilation time for now).

@bachase bachase changed the title Unexpected behavior with default transpilation set Unexpected behavior with default compilation set Mar 12, 2025
@Misty-W Misty-W added this to the 0.4.5 milestone Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants