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.

Sign up for GitHub

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

Simplify Relabel logic #2085

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 19 additions & 45 deletions compiler/qsc_eval/src/intrinsic.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -377,56 +377,30 @@ pub fn qubit_relabel(
return Err(Error::RelabelingMismatch(arg_span));
}

let mut map = FxHashMap::default();
map.reserve(left.len());
// Start with a mapping of each qubit to itself.
let mut mappings: FxHashMap<usize, usize> =
left.iter().copied().zip(left.iter().copied()).collect();
for (l, r) in left.into_iter().zip(right.into_iter()) {
// Trivial case where the qubit is already mapped to itself in the relabel, which can be short circuited.
if l == r {
continue;
}
match (map.contains_key(&l), map.contains_key(&r)) {
(false, false) => {
// Neither qubit has been relabeled yet.
swap(l, r);
map.insert(l, r);
map.insert(r, l);
}
(false, true) => {
// The right qubit has been relabeled, so we need to swap the left qubit with the
// new label for the right qubit.
let label = *map
.keys()
.find(|k| map[*k] == r)
.expect("mapped qubit should be present as both key and value");
swap(l, label);
map.insert(l, r);
map.insert(label, l);
}
(true, false) => {
// The left qubit has been relabeled, so we swap the qubits as normal but
// remember the new mapping of the right qubit.
let mapped = *map.get(&l).expect("mapped qubit should be present");
swap(l, r);
map.insert(l, r);
map.insert(r, mapped);
}
(true, true) => {
// Both qubits have been relabeled, so we need to swap new label for the right qubit with
// the left qubit and remember the new mapping of both qubits.
// This is effectively a combination of the second and third cases above.
let label_r = *map
.keys()
.find(|k| map[*k] == r)
.expect("mapped qubit should be present as both key and value");
let mapped_l = *map.get(&l).expect("mapped qubit should be present");
let mapped_r = *map.get(&r).expect("mapped qubit should be present");

// This swap is only necessary if the labels don't already point to each other.
if mapped_l != r && mapped_r != l {
swap(label_r, l);
map.insert(label_r, mapped_l);
map.insert(l, mapped_r);
}
}
// Check what each label currently maps to.
let mapped_l = *mappings.get(&l).expect("mapped qubit should be present");
let mapped_r = *mappings.get(&r).expect("mapped qubit should be present");

// We only need to swap if the label is not pointing to the correct qubit.
if mapped_l != r && mapped_r != l {
// Do a reverse lookup to find which label is currently mapped to the desired right qubit.
// 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.

.expect("mapped qubit should be present as both key and value");
swap(l, label_r);
mappings.insert(label_r, mapped_l);
mappings.insert(l, mapped_r);
}
}

Expand Down
Loading