Just checking in the mailing lists for example of the trilinos project and you ll readily verify my statement.

In particular I consider the use of static libs and of fortran for the blas libs particularly nasty since errors are at link or runtime instead at compiletime.
It gave us very nasty problems in our windows ports.

On 24 Jan 2016 15:34, "Karl Meerbergen" <karl.meerbergen@cs.kuleuven.be> wrote:

For academic research this is not an issue, but it is an issue where a little performance loss plays a role. I know one person who complained about Eigen for that reason: it was hard to get performance back of old code that used tuned BLAS libraries.

Living with headers only is a tough limitation. The idea that someone wil rewrite all available software to headers only does not make sense. It would imply rewriting many good libraries such as LAPACK, SLATEC, MUMPS, UMFPACK, QUADPACK, PARDISO, ARPACK, etc. If you want to solve a dense linear system, just use LAPACK. Most machines have compiled lapack and blas anyway.

We need both native implementations and bindings. Native implementations are nice to try out a concept, bindings are needed for specific functionalities, sometimes for performance. And, with a good build system, once the software packages are set up, linking is pretty straightforward.

Best,

Karl

On 24 Jan 2016, at 14:59, Riccardo Rossi <rrossi@cimne.upc.edu> wrote:

I would like to say that as a user, native implementation is way better than bindings.
Blas is always a nasty dependence to have in a project...and headeronly libs are the ideal situation.
I think for example this justifies the success of eigen over alternatives.
Cheers
Riccardo
On 24 Jan 2016 10:18, "Oswin Krause" <Oswin.Krause@ruhr-uni-bochum.de> wrote:
Hi,

I would still vote for the route to rewrite uBLAS based on BLAS bindings and providing a reasonable default implementation that also works well without memory assumptions.The main reason is that only having a fast gemm implementation does not really improve things, given that BLAS level 3 is a quite large beast.

Im still willing to donate my partial uBLAS rewrite, unfortunately I am a bit short on time to polish it(just finished my phd and have a huge load of work on my desk). But if someone opened a git-branch for that i could try to make the code ready (porting my implementation back to boost namespaces etc).

On 2016-01-23 18:53, palik imre wrote:
Hi All,

what's next? I mean what is the development process for ublas?

Now we have a C-like implementation that outperforms both the
mainline, and the branch version (axpy_prod). What will we do with
that?

As far as I see we have the following options:

1) Create a C++ template magic implementation out of it. But for
this, at the least we would need compile-time access to the target
instruction set. Any idea how to do that?

2) Create a compiled library implementation out of it, and choose the
implementation run-time based on the CPU capabilities.

3) Include some good defaults/defines, and hope the user will use
them.

4) Don't include it, and do something completely different.

What do you think?

Cheers,

Imre

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: Oswin.Krause@ruhr-uni-bochum.de
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: rrossi@cimne.upc.edu
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: karl.meerbergen@cs.kuleuven.be

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information.

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: rrossi@cimne.upc.edu