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

✨ Sorting designed SiDB gates #552

Open
wants to merge 165 commits into
base: main
Choose a base branch
from

Conversation

wlambooy
Copy link
Collaborator

@wlambooy wlambooy commented Oct 30, 2024

Description

This PR introduces an extension to is_operational and design_sidb_gates. The former is now able to return the simulation results that certify the status OPERATIONAL, which may then be used by the extension to the latter, which uses the simulation results to return the designed layouts in a specific ordering. This PR implements a simple heuristic for this ordering, namely it prefers the layouts for the the ground state isolation is large, ie., the energetic gap between the ground state and the first excited state. Specifically, it sorts by the minimum ground state isolation for each input.

To use this new feature when designing SiDB gates, make sure that all combinations are enumerated, and set the post_design_process parameter to PREFER_ENERGETICALLY_ISOLATED_GROUND_STATES.

Checklist:

  • The pull request only contains commits that are related to it.
  • I have added appropriate tests and documentation.
  • I have added a changelog entry.
  • I have created/adjusted the Python bindings for any new or updated functionality.
  • I have made sure that all CI jobs on GitHub pass.
  • The pull request introduces no new warnings and follows the project's style guidelines.

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

@Drewniok Drewniok added the enhancement New feature or request label Nov 1, 2024
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

@marcelwa
Copy link
Collaborator

@wlambooy is this PR still under active development, or can it be closed?

@wlambooy
Copy link
Collaborator Author

@wlambooy is this PR still under active development, or can it be closed?

I actually started merging it with main yesterday (big task in this case). It is a good starting point for the advanced circuit design I'm getting into. I'll let you know if this PR will stay or if it will be part of a different one.

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

clang-tidy made some suggestions

@wlambooy wlambooy requested a review from Drewniok February 14, 2025 01:02
@Drewniok
Copy link
Collaborator

Hi @wlambooy,

Many thanks for your hard work! Before I give you detailed feedback, could you, as we have discussed, extend the benchmark with gate design and operational domain? It will be super helpful in the future, especially for changes like this one. Many thanks!

@wlambooy
Copy link
Collaborator Author

I see now that I misread your comment; I added a specific benchmark for is_operational instead of operational_domain. Thinking about it, I think it might not be so interesting to put a grid-search operational domain benchmark if there is already one for is_operational in place, since BENCHMARK calls is_operational then 100 times, while grid-search operational domain also doesn't do so much more than calling is_operational some number of times.

For design_sidb_gates, I chose to benchmark the QuickCell algorithm, such that we can compare future improved versions of it. This benchmark does a lot more over is_operational than operational domain grid-search, since at the moment we also write all possible canvas layouts to a vector, which we may improve in the future.

Let me know if you think this is good :).

@Drewniok
Copy link
Collaborator

I see now that I misread your comment; I added a specific benchmark for is_operational instead of operational_domain. Thinking about it, I think it might not be so interesting to put a grid-search operational domain benchmark if there is already one for is_operational in place, since BENCHMARK calls is_operational then 100 times, while grid-search operational domain also doesn't do so much more than calling is_operational some number of times.

For design_sidb_gates, I chose to benchmark the QuickCell algorithm, such that we can compare future improved versions of it. This benchmark does a lot more over is_operational than operational domain grid-search, since at the moment we also write all possible canvas layouts to a vector, which we may improve in the future.

Let me know if you think this is good :).

That's great! Thank you!

@wlambooy wlambooy requested a review from Drewniok February 24, 2025 18:59
Copy link
Collaborator

@Drewniok Drewniok left a comment

Choose a reason for hiding this comment

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

Many thanks, @wlambooy! As discussed, I will try to find more time as soon as possible to look at it in more detail. Here are just a few comments that came up when I skimmed through it.

{
const std::size_t start_index = i * chunk_size;
const std::size_t end_index = std::min(start_index + chunk_size, all_canvas_layouts.size());

for (std::size_t j = start_index; j < end_index; ++j)
{
conduct_pruning_steps(all_canvas_layouts[j]);
conduct_pruning_steps(all_canvas_layouts.at(j));
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is the reason for this change? I guess you know that[] is faster but does not check bounds.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was under the impression that .at(.) does not really introduce any runtime overhead, and thus it is the preferred choice of array indexing in fiction. I could be wrong on that though, and that we prefer [] in performance-critical code. @marcelwa , could you enlighten us here?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Here, it says vector at() is slightly slower, due to the additional bounds checking. However, it is often negligible. . However, a small experiment shows the slightly opposite 😅

@@ -719,12 +664,12 @@ class design_sidb_gates_impl
// SiDBs cannot be placed on positions which are already occupied by atomic defects.
if constexpr (is_sidb_defect_surface_v<Lyt>)
{
if (skeleton_layout.get_sidb_defect(all_sidbs_in_canvas[i]).type != sidb_defect_type::NONE)
if (skeleton_layout.get_sidb_defect(all_sidbs_in_canvas.at(i)).type != sidb_defect_type::NONE)
Copy link
Collaborator

Choose a reason for hiding this comment

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

same here

{
continue;
}
}
lyt.assign_cell_type(all_sidbs_in_canvas[i], sidb_technology::cell_type::LOGIC);
lyt.assign_cell_type(all_sidbs_in_canvas.at(i), sidb_technology::cell_type::LOGIC);
Copy link
Collaborator

Choose a reason for hiding this comment

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

same here

namespace detail
{

template <typename Lyt>
Copy link
Collaborator

Choose a reason for hiding this comment

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

please add a docstring.


#endif // COMPARE_BY_ENERGETIC_GAP_HPP

//
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this code still needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I will use it to write docstrings later. It will be removed in the future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants