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

Singletons #110

Closed
ffreyer opened this issue Apr 2, 2021 · 2 comments
Closed

Singletons #110

ffreyer opened this issue Apr 2, 2021 · 2 comments

Comments

@ffreyer
Copy link
Collaborator

ffreyer commented Apr 2, 2021

I want lattice and greens iterators to be created just once since they can be rather large. In the case of CombinedGreensIterator it's also very worth it to group measurements that use it.

The current implementation achieves this by saving types instead of objects in measurements and later resolving those to types. This works but is kind of awkward and complicated. With the addition of wrapper types for lattice iterators this has become even more awkward. Some of those wrappers require data from user input, leading to half-constructed types.

The alternative would be to use a global lookup array or perhaps dictionary. Conceptually we would want something like lookup = Dict(hash(dqmc, lattice_iterator_type) => lattice_iterator), though hash(dqmc) would change as measurements are added.

@ffreyer
Copy link
Collaborator Author

ffreyer commented Aug 26, 2021

Perhaps it would make sense to store iteration information with the lattice have LatticeIterator's be a slim interface to that information. That way the iterator would often just be an empty struct, and the necessary data would be initialized in measurements are grouped in generate_groups.

@ffreyer
Copy link
Collaborator Author

ffreyer commented Dec 13, 2021

I implemented a LatticeIteratorCache attached to DQMC in #137 which holds almost all the necessary data. So lattice iterators are now essentially free in terms of memory and we don't need to make them unique anymore. I also implemented template versions which are probably unnecessary.
For greens iterators it's not a memory problem. The iterators themselves are tiny. Instead it's a performance problem - we don't want to iterate through the same greens iterator multiple times. And if we group measurements based on their greens iterators we naturally reduce that to just one.

@ffreyer ffreyer closed this as completed Dec 13, 2021
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

No branches or pull requests

1 participant