Support for integers in sparse matrix types

[cdeterman]

I read on the viennacl mailing list a mention of adding additional templates such as int so I am creating this issue to formally request it as well :-)

[karlrupp]

Thanks ;-) Since vectors and dense matrices already support integers, I adjusted the title accordingly.

[cdeterman]

@karlrupp the matrix objects can be created but the methods don't appear to exist. For example, if I try to multiply two integer matrices together I get the following error:

ViennaCL: Internal error: The generator cannot handle the statement provided: GEMM only supported for float/double

[karlrupp]

Thanks, @cdeterman , frankly I was not aware of the limitation for GEMM in OpenCL (i.e. I haven't written that code)

[ptillet]

Hi,

Since I have written this code, I can give a bit more explanations :p The
only reason why I postponed support of integers in the generator was
because of overflow related issues. i.e., it is not clear whether the
accumulator of an integer dot product should be float, double, int or long.
I think that this information should be provided by the user, but didn't
think further about it.

Philippe

On Mon, Aug 3, 2015 at 1:24 PM, Karl Rupp notifications@github.com wrote:

Thanks, @cdeterman https://github.com/cdeterman , frankly I was not
aware of the limitation for GEMM in OpenCL (i.e. I haven't written that
code)

—
Reply to this email directly or view it on GitHub
#153 (comment)
.

[cdeterman]

@PhilippeTillet perhaps this could be a separate issue? It seems to me (perhaps a bit naively) that a safe default would be to have the accumulator default to int when multiplying int matrix objects. Or are you suggesting that users should convert an int matrix to a float/double viennacl matrix to use OpenCL methods like GEMM?

[ptillet]

Contrary to CUDA, the size of an int in OpenCL is well defined (32 bits).
You're right, and in most cases the accumulator won't exceed 4 billions.
Still, in some cases -- (e.g., computing the covariance matrix of some
discrete random variables) -- the accumulator could certainly overflow.

Additionally, it is very possible that GEMM on integer types would not
deliver good performance. Both fma and mad operate on floating point
parameters (
https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/fma.html).
While, in some cases, good performance could be retained using mad24, I
have no idea how this feature could be exposed to the user :(

On Tue, Aug 4, 2015 at 8:41 AM, Charles Determan notifications@github.com
wrote:

@PhilippeTillet https://github.com/PhilippeTillet perhaps this could be
a separate issue? It seems to me (perhaps a bit naively) that a safe
default would be to have the accumulator default to int when multiplying
int matrix objects. Or are you suggesting that users should convert an int
matrix to a float/double viennacl matrix to use OpenCL methods like GEMM?

—
Reply to this email directly or view it on GitHub
#153 (comment)
.

[karlrupp]

@PhilippeTillet : Keep in mind that ViennaCL does not allow mixing numeric types in computations.
Also, I see no reason why

matrix<int> B, C;
// init here
matrix<int> A = prod(B, C);

should have accumulator semantics other than 'int'. In fact, it would be quite surprising to see float or double as accumulator here. Moreover, non-optimal performance is better than no performance at all ;-)