-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add Matrix::subPipeline{,Const}
#898
Conversation
cscs-ci run |
3b818d8
to
f2fd48b
Compare
cscs-ci run |
Matrix::subPipeline(Const)
Matrix::subPipeline{,Const}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job!
About naming, it is a bit difficult to give better suggestions. An issue is that we are acting on a Matrix, which is a set of Tiles each one with its own pipeline. And with mat.subPipeline()
we are actually getting a sub-pipeline for each tile in the matrix (or for a subset of them in the future). Plural? But it is not given that a matrix have multiple tiles.
Probably I would start thinking in terms of scopes (along the lines of what you suggested with "nested") mat.createNestedScope
/mat.createNestedConstScope
?
… read-after-read optimization
cscs-ci run |
a379c22
to
5adba0b
Compare
cscs-ci run |
Fixes part of #868.
This adds the naive, non-optimized, version of getting a
Matrix
from anotherMatrix
with tiles in a sub-pipeline, i.e. tile accesses from the sub-pipelinedMatrix
are sequenced after all previous tile accesses to the originalMatrix
and before all later tile accesses to the originalMatrix
.The missing optimization is merging of read-only accesses between the parent
Matrix
and the sub-pipelinedMatrix
. Creating a sub-pipelinedMatrix
currently implies one "hidden" read-write access to the parentMatrix
. Releasing the sub-pipelinedMatrix
releases all subsequent accesses from the parentMatrix
.In the end this naive version required very few changes to
Matrix
, and did not require a separate type. I think this is a good thing. One of the open questions from this is ifMatrix
should have adone
method? As far as I can tellRetiledMatrix
should be possible to refactor intoMatrix
in exactly the same way and that would also introducedone
intoMatrix
.This can already now be used in conjunction with
View
s to access a sub-matrix with sub-pipelines. To have sub-matrices with sub-pipelines we first need to updateDistribution
.Are the names
subPipeline
andsubPipelineConst
understandable? I'd like to avoidsubMatrixPipeline
since this doesn't yet handle sub-matrices. "nest" is a word that I'm thinking could fit well to the "sub-pipeline" aspect of the access but not sure yet.nest
/nestRead
/nestConst
/nested*
. In order to allow optimizing access to only a sub-matrix in the future I'd imagine the function signature would be expanded in the future to look like:subPipeline/nested/whatever(SubTileMatrixSpec/SubElementMatrixSpec const& = full_matrix)
and then it'd be nice if the name would cleanly cover the future use cases as well but this future version could of course simply get a new name. Suggestions welcome.