Re: [ublas] Matrix multiplication performance

Subject: Re: [ublas] Matrix multiplication performance
From: Riccardo Rossi (rrossi_at_[hidden])
Date: 2016-01-24 10:00:07

Dear Karl,
   Let me disagree just about your last point:

Linking blas and lapack IS a big pain for any moderately large project.

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.

Cheers
Riccardo
On 24 Jan 2016 15:34, "Karl Meerbergen" <karl.meerbergen_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]>
> 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_at_[hidden]
>>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>>> Sent to: Oswin.Krause_at_[hidden]
>>>
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: rrossi_at_[hidden]
>>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: karl.meerbergen_at_[hidden]
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more
> information.
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: rrossi_at_[hidden]
>