These are chat archives for elemental/chat

25th
Dec 2016
Jack Poulson
@poulson
Dec 25 2016 21:17
because there was a case where a routine would create an El::Grid but the El::DistMatrix class accepts a const El::Grid*
in particular, this was in the context of the sparse-direct solver data structures, which are kind of a mess
I am starting to experiment with introducing std::unique_ptr and to avoid raw pointers unless they are "observing" pointers with no memory management
I think the combination of std::unique_ptr and properly documented raw, observing pointers will be a significant improvement
Ryan H. Lewis
@rhl-
Dec 25 2016 23:13
Also happy holidays
Sounds like a case for a move ctor from what your describing
You have a thing that gets made and it's lifetime needs to be given to something else
I try to avoid all smart pointers
And it sounds like promoting your grid to an xvalue if possible and handing it to your distmatrix would do the trick
Jack Poulson
@poulson
Dec 25 2016 23:18
but the original El::Grid shouldn't be destroyed
Ryan H. Lewis
@rhl-
Dec 25 2016 23:19
Wait so you need to store a container of grids?
Jack Poulson
@poulson
Dec 25 2016 23:19
the overheads are low enough on std::unique_ptr that I think it is considered a best practice
Ryan H. Lewis
@rhl-
Dec 25 2016 23:19
Why not just maintain a vector of them then?
Jack Poulson
@poulson
Dec 25 2016 23:19
no, various distributed data structures need different El::Grid instances over different sets of processes
maintain an std::vector of them where? and on which processes?
Ryan H. Lewis
@rhl-
Dec 25 2016 23:20
Maybe im misunderstanding but it sounds like in the distmatrix
Or whatever is supposed to hold the lifetime of the grids
Based on your last sentence it sounds like a distributed data structure has a member which represents multiple grids
I would still use move semantics to move generated grids into that vector
Jack Poulson
@poulson
Dec 25 2016 23:23
an El::DistMatrix currently holds a single const El::Grid*
Ryan H. Lewis
@rhl-
Dec 25 2016 23:23
Yeah, I propose replace with vector<Grid>
Jack Poulson
@poulson
Dec 25 2016 23:23
the distributed sparse-direct solvers involve trees of distributed matrices over different subsets of processes, and each requires a potentially different El::Grid pointer
Ryan H. Lewis
@rhl-
Dec 25 2016 23:24
Or maybe some other container depending on your needs
Jack Poulson
@poulson
Dec 25 2016 23:24
using a flat data structure for the El::Grid's for the sparse-direct solvers would eliminate all of the niceness of using recursive implementations to traverse the trees
what is your aversion to std::unique_ptr?
Ryan H. Lewis
@rhl-
Dec 25 2016 23:25
Can you share a link to some code so I can grok?
Jack Poulson
@poulson
Dec 25 2016 23:25
see, e.g., elemental/Elemental@75c5f5a
Ryan H. Lewis
@rhl-
Dec 25 2016 23:26
I mean why do you need a unique_ptr, it seems like you just need to move some grids around
Jack Poulson
@poulson
Dec 25 2016 23:27
and elemental/Elemental@69b6eb8 for the El::Grid change
Ryan H. Lewis
@rhl-
Dec 25 2016 23:27
Be back in a bit. On a plane :) taking off