|
|
Ublas : |
Subject: Re: [ublas] Matrix multiplication performance
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2016-01-24 10:17:56
Hi,
the obvious solution to this is to link to the c-cindings (cBLAS,
LAPACKE). While BLAS is truly a PITA, most systems have quite sane cBLAS
bindings (notable exception is OpenBLAS...) and often it is enough to
check whether the system has some libcBLAS.so somewhere in the path.
the big issue of having a header only BLAS are the long, long, long
compile times.
On 2016-01-24 16:00, Riccardo Rossi wrote:
> 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]
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: Oswin.Krause_at_[hidden]