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

Simplify Relabel logic #2085

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

swernli
Copy link
Collaborator

@swernli swernli commented Dec 31, 2024

This simplifies the relabeling logic to collapse the four match cases down into one for easier readibility. It avoids trying to optimize special cases for qubits that may not have been mapped and treats all labels as having an intial mapping to themselves.

Based on feedback from @DmitryVasilevsky in #2082 (comment)

This simplifies the relabeling logic to collapse the four match cases down into one for easier readibility. It avoids trying to optimize special cases for qubits that may not have been mapped and treats all labels as having an intial mapping to themselves.
// This tells us which label to use in the swap, which we will use in the update of the mappings too.
let label_r = *mappings
.keys()
.find(|k| mappings[*k] == r)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This step is linear, which makes the whole thing quadratic. Granted, our qubit count won't be large, but let's figure out linear algorithm (in average case). Should be doable with mutable array and mutable hash map.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous implementation avoided doing this reverse lookup every time by only performing it when necessary. You are right, I wouldn't expect Relabel to be called with very large lists of qubits, and even if it were I don't think this would take lots of time unless relabels were happening very frequently.

If we do want to optimize this further, we could maintain two maps, one from label to actual and one from actual to label. Or, if we are comfortable with some higher memory costs, we could use an IndexMap for fast lookup (but then any gaps in qubit ids would be empty entries in the underlying vector). Overall, I'm don't really think it's worth optimizing this further until we have reason to believe that large lists of qubits will be relabeled frequently, and then we can perf test to find the right optimizations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should eventually move this to simulator. And we could improve it at that time. For now, I suggest we add a comment that this step may take O(n) time, but we are only expecting small number of qubits.

@swernli swernli enabled auto-merge January 8, 2025 18:30
@swernli swernli disabled auto-merge January 8, 2025 18:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants