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
[DAGCircuit Oxidation] Refactor bit management in CircuitData
#12372
base: main
Are you sure you want to change the base?
Conversation
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 9019232369Details
💛 - Coveralls |
struct BitAsKey { | ||
/// Python's `hash()` of the wrapped instance. | ||
hash: isize, | ||
/// The wrapped instance. | ||
bit: PyObject, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we maybe should remove one of the layers of abstraction here. It's something I've been thinking about in #12205 is that the source of truth for bits is still python but for interaction from rust space this isn't super ergonomic. I'm wondering if instead of playing games like this we try flattening the two representations. I guess the complexity is things like register and index (although #11596 will take care of that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is what you were getting at, but I was thinking longer term that we'll want/need to make it possible to construct circuits from Rust space without creating any Python objects at all. We might not be at that point yet, but it might to be thinking about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's basically what I was getting at, having a pattern for making a circuit without any python interaction is what we'll want longer term. The example I have for making circuits from rust space right now still needs a py
handle because we need to instantiate Qubit
objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd agree as well. BitAsKey
isn't new here, though. I've only moved it from CircuitData
.
Also, the source of truth for bits is CircuitData
. It owns its bits, and QuantumCircuit
simply "references" them.
I'm rethinking a bit of this PR (specifically the stuff with packing and interning) so I'm going to put this into draft for now. The |
Summary
This is part of the work we're doing to port
DAGCircuit
to Rust. It's work I've pulled out of a local branch where I'm doing that port, in an effort to reduce the size of that eventual PR.Details and comments
Qubit
andClbit
representation.BitData
which encapsulates maintaining a mapping between native Rust bit types and Python bit types. This significantly cleans up the code inCircuitData
and makes it reusable forDAGCircuit
.InternContext
into a genericSlottedCache
data structure, which implements slotted caching for anyT
which isHash
andEq
. This is used to implement the new traitInterner<Vec<Qubit>>
andInterner<Vec<Clbit>>
forCircuitData
.Interner
trait, for defining interner semantics for containers likeCircuitData
(andDAGCircuit
).PyNativeMapper
trait, for defining a mapping between Python and native Rust types for containers likeCircuitData
.InstructionPacker
, implemented for containers which provide intern semantics for bit lists and mappings from Python bits to native bits. This allows us to share our instruction packing implementation betweenCircuitData
andDAGCircuit
.