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@lists.boost.org> 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.

--

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