You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After we have the full rust-native core data model in #13264 we can then expose a compiled language interface directly to that data model. Having a compiled language interface will let users from other programming languages besides Python leverage Qiskit for quantum computation. But also for Python users having this interface would let Python compiled extensions interface with Qiskit at a lower level directly from the extension. This can be exceedingly powerful for accelerating applications of Qiskit in python, the best example is numpy which exposes a C API which is how Qiskit interfaces with numpy arrays from Rust and has been key for our performance as we've been doing more in Rust.
To start this interface should be very low level and only express a basic interface for building a QuantumCircuit with standard gates (or other operations defined solely by Qiskit in rust) and then transpiling that circuit (and maybe individual transpiler pass functions). Also, I think to start we should consider this API experimental and not commit to it being a fully stable interface as Qiskit has never had an API like this before, but we should also strive to keep the interface public and stable as defined by the stability policy. Basically say it'll be stable but not guarantee it at least for the first few releases while we figure out the best patterns here.
The text was updated successfully, but these errors were encountered:
What should we add?
After we have the full rust-native core data model in #13264 we can then expose a compiled language interface directly to that data model. Having a compiled language interface will let users from other programming languages besides Python leverage Qiskit for quantum computation. But also for Python users having this interface would let Python compiled extensions interface with Qiskit at a lower level directly from the extension. This can be exceedingly powerful for accelerating applications of Qiskit in python, the best example is numpy which exposes a C API which is how Qiskit interfaces with numpy arrays from Rust and has been key for our performance as we've been doing more in Rust.
A C FFI is a natural choice for this as most languages can interface with C, including Python and Rust, and defining a C API via rust is very simple, see: https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c.
To start this interface should be very low level and only express a basic interface for building a
QuantumCircuit
with standard gates (or other operations defined solely by Qiskit in rust) and then transpiling that circuit (and maybe individual transpiler pass functions). Also, I think to start we should consider this API experimental and not commit to it being a fully stable interface as Qiskit has never had an API like this before, but we should also strive to keep the interface public and stable as defined by the stability policy. Basically say it'll be stable but not guarantee it at least for the first few releases while we figure out the best patterns here.The text was updated successfully, but these errors were encountered: