VariationalSolver and Assembler LRU caching #2998
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a draft. It is intended to be a proof of concept to allow discussion. Significant cleanup is needed.
Adding an LRU cache for solvers means that we can make the code
just* as fast as
* there is a small additional cost to hash the forms to determine a cache hit or miss.
It is significant to note that in the former case non-persistent forms have been used, that is,
u*v*dx
instead ofform = u*v*dx; ...; solve(form...)
. The code is still fast.Discussion
This is somewhat of a controversial suggestion. Solvers consume a lot of memory so we really don't want to leak them. I believe that easy configuration, sufficient documentation and sane defaults are enough to handle this.
One of the things that most appeals to me about this solution is that we can apply it generally across all of Firedrake to improve our strong scaling. Things like
Assembler
,Interpolator
can reuse the same concepts. It could also help in the adjoint where stashingAssembler
,Interpolator
etc objects is difficult.Related GitHub discussion: #2946
Required PRs
Remaining tasks