64-bit capable containers about clsparse HOT 6 OPEN

I vote for cl_ulong.

from clsparse.

I also lean in this direction; it would be nice to think we could handle 64bit sizes, but what would be the occurance of this in the 'real world'? Is it enough to just change cl_int to cl_uint? 64-bit data/registers can reduce kernel performance.

from clsparse.

If we change that we need to check if the kernel wrapper is receiving correct data type and probably the kernel parameters string need to be changed accordingly. kernel parameter string defines the types of the kernel parameters by substituting #define variables in the kernel code.

I will take care of it.

from clsparse.

The decision of whether we should switch our structures to use 64-bit members is somewhat dependent on how this affects kernel performance. I talk about this some in this comment: #20 (comment)

This idea is dependent on the new benchmark framework proposed in #21. We need to be able to measure performance of this change to determine if this is appropriate.

from clsparse.

I've going to take care of this as I work on SpM-dM.

I've been looking at the OpenCL API, and all the API's that take size parameters are taking size_t's. I think that is a good standard, and I am going to work on changing our data structures to use size_t's. We have to be careful not to copy size_t's to clSetKernelArg(), because the device may have a different address depth than host. We should dynamically detect the address depth of the device and cast the values we pass into clSetKernelArg() and equivalents.

from clsparse.

From my other projects we were taking cl_ulong for sizes. Be careful with the matrices, type for indexes are important.

from clsparse.