Re: [ublas] CI setup

Subject: Re: [ublas] CI setup
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-04-30 13:58:17

On 2018-04-30 09:20 AM, Cem Bassoy via ublas wrote:
>
>
> On Mon, Apr 30, 2018 at 10:05 AM, David Bellot via ublas 
> <ublas_at_[hidden] <mailto:ublas_at_[hidden]>> wrote:
>
>>         You mentioned some possible refactoring that would make
>>         integration easier. Can you please outline what refactoring you
>
>
>     ​Super open to refactoring of ublas.
>     Curious to know what you have in mind.
>
>
> Yes, thx. In general I would have like to compare the current boost 
> implementation with blaze and eigen.
> I think there are several features or also neglect which we might add 
> to uBLAS.
>
> - Should we integrate smart expression templates? I think there was a 
> gsoc project but I am not sure. What was the output?
> - Are (smart) expression templates really required?
> - How often do expressions like A = B*C + D*D - ... occur in numerical 
> applications?
> - Should we provide a fast gemm implementation of the Goto-Algorithm 
> like in Eigen?

Not sure about the specific questions, but I definitely think 
Boost.uBLAS should provide the means to handle arbitrary expressions, 
and allow for optimised backends to be matched (example: recognize `D = 
A * B + C` as a statement that can be vectorized and evaluated using 
fused multiply-add instructions, wherever available).

>
> And regarding the code infrastructure:
>
> - Do we need iterators within matrix and vector template classes? Or 
> can we generalize the concepts?
> - Can we maybe simplify/replace the projection function with 
> overloaded brackets?
I don't have an opinion on that question yet.

>
> General questions:
>
> - Shall we build uBLAS a high-performance library?

Not quite sure what you mean by that question.

> - Could it also be a convenient wrapper library with good interfaces 
> to high-performance libraries such as OpenBLAS?

Yes, definitely. One of the GSoC projects is right now looking into 
using OpenCL backends to provide GPU support. The infrastructure for 
that should be easily extensible, so we could have additional 
high-performance backends.
The trick then is to find ways to map specific (smart ?) expression 
types to available backend "kernels", and figure out (part compile-time 
part runtime) which backend to use.
I have worked on such an infrastructure in OpenVSIP (see the "Dispatch 
Engine" part in http://openvsip.org/doc/architecture.html) and think 
that something like that would be useful in Boost.uBLAS as well.

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...