What object should we use for DAG manipulation? #13
Closed
jordandsullivan
started this conversation in
Ideas
Replies: 1 comment
-
We have decided to stick with the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What are we doing now?
For DAG optimization, currently we are making use of the
qiskit.DAGCircuit
object, which relies on being initialized by a QiskitCircuit object. As of Sep 13, 2024, if a user inputs aQiskitCircuit
, ucc.compile is doing to wholly unnecessary steps of translating from QiskitCircuit --> OpenQasm --> QiskitCircuit --> DAGCircuit:ucc/ucc/compile.py
Lines 20 to 23 in eb83869
ucc/ucc/transpilers/ucc_transpiler.py
Lines 20 to 24 in eb83869
But if we got rid of these unnecessary steps for Qiskit inputs, using a QiskitCircuit object as the fundamenal unit of of our DAG object makes UCC lack parity between frontends (i.e. if I say
ucc.compile(cirq_circuit)
, we are on the back end translating CirqCircuit --> OpenQASM --> QiskitCircuit --> DAGCircuit, whereas aQiskitCircuit
requires no translation to initialize aDAGCircuit
.Alternatives
For parity across frontends and to avoid relying on the QiskitCircuit object as such a fundamental part of our compilation, another option would be to use for instance BQSKit, which already accepts QASM code and has their own IR. It seems to have a lot of advanced features that we could choose a subset of for our default compiler pass.
However, Qiskit plans to move most of their code to Rust, and already their DAG object is calling Rust on the backend, so maybe this is fine?
Beta Was this translation helpful? Give feedback.
All reactions