Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 14 01:33
    poulson closed #276
  • May 14 01:33
    poulson commented #276
  • May 14 01:30

    poulson on master

    Update README.md (compare)

  • May 14 01:24

    poulson on master

    added logo (compare)

  • May 10 21:37
    jedbrown commented #276
  • May 10 21:25
    poulson commented #276
  • May 10 21:21
    jedbrown commented #276
  • May 10 17:08
    poulson commented #276
  • May 10 17:03
    tesch1 opened #276
  • Apr 10 13:18
    JM1 commented #275
  • Apr 10 13:16
    JM1 synchronize #275
  • Apr 10 08:56
    JM1 opened #275
  • Mar 06 03:47
    Raviteja1996 closed #274
  • Mar 05 05:46
    Raviteja1996 opened #274
  • Feb 11 21:53
    BenBrock commented #228
  • Feb 11 21:52
    BenBrock commented #228
  • Feb 11 21:51
    poulson commented #228
  • Feb 11 21:50
    poulson commented #228
  • Feb 11 21:45
    BenBrock commented #228
  • Jan 23 23:57
    adambaskerville commented #273
Jack Poulson
@poulson
it's almost 2017 now, and C++14 was a minor release, so I think this should be reasonable now
the 0.87 branch will remain C++11
Ryan H. Lewis
@rhl-
+1
Jack Poulson
@poulson
I am currently in a deep dive working towards unifying all of the LP IPM implementations and translating DistMultiVec, DistGraph, DistSparseMatrix, DistMap to accept a Grid rather than an mpi::Comm and for Matrix to support some trivial Grid and alignment arguments to help enable duck-typing
(and greetings from Kona)
hopefully a huge amount of code can be deleted soon
Ryan H. Lewis
@rhl-
Cool
Jack Poulson
@poulson
bah, it seems that it would be useful to decide on whether we should switch to classes accepting std::shared_ptr's of El::Grid rather than const references since some routines (e.g., Bisect) create a tree of Grids
I don't have a good feel for the overhead of std::shared_ptr
Jack Poulson
@poulson
My thinking is no (due to the fact that DistMatrixis assumed to be cheap to construct and destruct) and that perhaps the sparse-direct solver should create a data structure for the tree of process grids
Ryan H. Lewis
@rhl-
Why a sharedptr? A tree is a container, but a shared_ptr doesn't really reference containers
I mean a shared_ptr of grid is not a container of grids
Jack Poulson
@poulson
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-
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
but the original El::Grid shouldn't be destroyed
Ryan H. Lewis
@rhl-
Wait so you need to store a container of grids?
Jack Poulson
@poulson
the overheads are low enough on std::unique_ptr that I think it is considered a best practice
Ryan H. Lewis
@rhl-
Why not just maintain a vector of them then?
Jack Poulson
@poulson
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-
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
an El::DistMatrix currently holds a single const El::Grid*
Ryan H. Lewis
@rhl-
Yeah, I propose replace with vector<Grid>
Jack Poulson
@poulson
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-
Or maybe some other container depending on your needs
Jack Poulson
@poulson
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-
Can you share a link to some code so I can grok?
Jack Poulson
@poulson
see, e.g., elemental/Elemental@75c5f5a
Ryan H. Lewis
@rhl-
I mean why do you need a unique_ptr, it seems like you just need to move some grids around
Jack Poulson
@poulson
and elemental/Elemental@69b6eb8 for the El::Grid change
Ryan H. Lewis
@rhl-
Be back in a bit. On a plane :) taking off
Jack Poulson
@poulson
Comments welcome! elemental/Elemental#214
Jack Poulson
@poulson
the sparse-direct interface shouldn't be so laughably complicated anymore
Ryan H. Lewis
@rhl-
I'm without a laptop this week. Just have a phone
I can review but it would require Waiting until Jan 1
Jack Poulson
@poulson
no worries
the improvement in the interface is substantial enough that it will be worth merging once the dust settles (probably in several more days)
Jack Poulson
@poulson
It seems someone removed the links to Elemental on the Wikipedia pages for permissively licensed LP, QP, and SOCP solvers :-(
also, I am bundling in a Mathematical Programming Software (MPS) reader in the sparse-direct changeset