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

Persistent team policy #226

Open
kuberry opened this issue Dec 4, 2020 · 1 comment
Open

Persistent team policy #226

kuberry opened this issue Dec 4, 2020 · 1 comment
Assignees
Labels

Comments

@kuberry
Copy link
Collaborator

kuberry commented Dec 4, 2020

Currently, the ParallelManager creates a team_policy instantiation each time a functor is requested, without persistence. The next time a functor is called, it needs to be done again.

Particularly for within the GMLS class, this means that many scratch allocations are being made that could be made once for all time if this were made persistent. Previously the ParallelManager class has been passed around, keeping track of scratch space and levels, with a copy constructor that consists only of ints/doubles. This will no longer be the case if the PM is managing the policy and its persistence.

@kuberry kuberry added the TOOLKIT label Dec 4, 2020
@kuberry kuberry self-assigned this Dec 4, 2020
@kuberry
Copy link
Collaborator Author

kuberry commented Oct 31, 2021

Addressed partially by #257 where team policy is reused.

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

No branches or pull requests

1 participant