Hey,
> So today I went back to ViennaCL. I tried to move the equivalence
> column&trans <=> row¬rans upwards in the dispatching mechanism but it
> turns out to be impossible, because matrix<T,row_major> is not (and
> should not be) convertible to matrix<T, column_major>, rendering the
> underlying signature inappropriate...
yep, having the storage layout tag explicitly encoded in the type is
something I'm not at all happy with. It is certainly useful in uBLAS,
but it doesn't quite fly with what we want to do.
> I am very skeptical so as to how to handle this problem. I am thinking
> about changing the internal signature to something more "low-level",
>
> void gemm(bool/*is_A_trans*/,bool/*is_B_trans*/
>
> ,const vcl_size_t /*M*/, const vcl_size_t /*N*/, const
> vcl_size_t /*K*/, const T /*alpha*/
>
> ,viennacl::backend::mem_handle const & /*A*/ , const
> vcl_size_t /*A_internal_size1*/, const vcl_size_t /*A_internal_size2*/
>
> ,const vcl_size_t /*A_start1*/, const vcl_size_t /*A_start2*/,
> const vcl_size_t /*A_inc1*/, const vcl_size_t /*A_inc2*/
>
> ,viennacl::backend::mem_handle const & /*B*/, const vcl_size_t
> /*B_internal_size1*/, const vcl_size_t /*B_internal_size2*/
>
> ,const vcl_size_t /*B_start1*/, const vcl_size_t /*B_start2*/,
> const vcl_size_t /*B_inc1*/, const vcl_size_t /*B_inc2*/
>
> ,const T /*beta*/, viennacl::backend::mem_handle & /*C*/, const
> vcl_size_t /*C_internal_size1*/, const vcl_size_t /*C_internal_size2*/
>
> ,const vcl_size_t /*C_start1*/, const vcl_size_t /*C_start2*/,
> const vcl_size_t /*C_inc1*/, const vcl_size_t /*C_inc2*/);
Yes, this is a good option. I think we can reduce the many arguments by
wrapping informations into a common struct, e.g.
struct backend_matrix
{
viennacl::backend::mem_handle h_;
vcl_size_t internal_size_1_;
...
bool is_trans_;
};
and only pass
gemm(alpha, A, B, beta, C);
rather than a lengthy list of parameters which we will get crazy about.
Note that this is also more in line with the object-oriented C-interface
in the shared libviennacl library.
Anyhow, the simplification of gemm() and friends is similar to what I
already had in mind for reducing compilation times and the code required
for 'worker functions' in the respective backends. Right now we have
function overloads for transposed/non-transposed matrix parameters in
each of the backends, which is clunky and duplicates quite some code.
Also, such a more BLAS-like interface makes it easier for us to hook in
other libraries as backends :-)
> While this solution is acceptable to me, I fear that it will introduce a
> lack of harmony considering that some other functions will stay
> otherwise like
>
> template <typename NumericT, typename F,
>
> typename ScalarType1>
>
> void am(matrix_base<NumericT, F> & mat1,
>
> matrix_base<NumericT, F> const & mat2, ScalarType1 const
> & alpha, vcl_size_t len_alpha, bool reciprocal_alpha, bool
> flip_sign_alpha)
We can (and probably should) migrate them in the same manner.
> The only reasonable solution I see is to clearly separate in the code
> the functions which could be linked with BLAS (and give them a lower
> level signature), from the other ones. For example, putting them in two
> separate files... is there any problem with doing this?
We should take this opportunity to further decouple the convenience API
from the actual numerical kernels. This would also pave the way for
ViennaCL 2.0.0, where I'd like the C++ API to be sitting entirely on top
of the shared libviennacl (and/or other BLAS backends if enabled). Of
course this won't be done within a few days, but I think this is a great
long-term perspective :-)
Does this make sense to you?
Best regards,
Karli
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
