[temp453463343]

Great.. another C++ linear algebra library...

  boost::uBLAS
  eigen
  armadillo
  a dozen other...

why not contribute to an existing project?

The reoccurring bifurcation of talent and resources in the open source community is really disheartening. Can't we focus on one or two libraries and make them actually good? Or at least fork off of something that already exists and add your own features. I look at benchmarks of the existing tools and one library will do one operation very efficiently, while another will work well with something. Often the differences in speed are huge (more than a factor of 10). So I end up having to flip a coin in choosing which library to use.

[poulson]

With all due respect, did you even read the title of the post? This is a distributed-memory library, unlike all of the ones you just mentioned. This is a fundamental difference in design and capability. The only related libraries are ScaLAPACK, PLAPACK, and DPLASMA.

[temp453463343]

And why exactly can't that be made part of an existing library?

[poulson]

Essentially all distributed dense linear algebra libraries are built on top of sequential dense linear algebra libraries (mine as well, but on the interface rather than the implementation). Distributed libraries are at least an order of magnitude more complex than their sequential counterparts.

[temp453463343]

I guess I don't get what you're saying:

the C++ linear algebra libraries are basically syntactic sugar for interacting with optimized Fortran libraries like BLAS, LAPACK, etc. (I'm sure I'm overlooking some complexity here, because the C++ libraries, while linking to the same Fortran libraries have very different run times)

Yours interacts with ScaLAPACK and other distributed memory libraries.

Why would it not be possible to simply extend say armadillo or eigen to interact with distributed memory libraries? If you need more syntax, then extend the interface.

[poulson]

Elemental implements, as opposed to wraps, the distributed-memory algorithms. In other words, it does not call any library like ScaLAPACK; it is an alternative approach. Elemental builds on top of BLAS/LAPACK/MPI in order to provide a nice interface to dense linear algebra on clusters/supercomputers.

The other major difference is that sequential libraries tend to get away with letting users not have to worry about where data resides. This is of fundamental importance in distributed libraries, and, for this reason, it is usually a bad idea to think of simply modifying sequential APIs.

[temp453463343]

So why not contribute to (or extend) say ScaLAPACK to make it do what you need and add a wrapped to an existing linear algebra library?

Looking at ScaLAPACK, it's been developed since 1995. I've never touched it, but it's probably many many lines of code (and maybe a few PhD thesis) with all sorts of kinks worked out that will take you decades to iron out yourself. To throw out all that knowledge/work/man-hours and to start from scratch seems like a waste.