- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hello,

I have a three array variation of the CSR format as a sparse matrix. The rowIndex vector is of type INTEGER (KIND=8), while all the rest of the integers are KIND=4. Because of memory and code limitations, I cannot use the option -i8 when compiling.

Is there any way to use MKL_SPARSE_D_CREATE_CSR and the rest of the functions with rows_start and rows_end defined as INTEGER (KIND=8)?

Thanks,

Matias

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I don't think so. Consider the implications. If mixing different size integer arguments to MKL routines was allowed, they would need to implement 2^6 = 64 different versions of MKL_SPARSE_D_CREATE_CSR, and similarly for other MKL routines that take one or more integer arguments.

They decided long ago to provide two versions of the libraries: LP64 and ILP64.

However, note that this restriction applies only to integer variables that are actual arguments to MKL routine calls. You are free to use whatever integer sizes suit you for other variables.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi mbermann,

So mecej4 is absolutely correct, but the discussion could be a little more nuanced. The world of sparse formats is trying to solve the general problem of balancing representing the sparse matrix with as small of a memory footprint while still making the format useful for a wide range of operations. There is probably a good reason to consider use of all scalar integer inputs as large integers (like std::int64_t) but make the arrays of integers use as small of a size as is possibly necessary to represent their internal sizes.

For CSR4 format:

row_start/rows_end are of length nrows and contains integers that represent an offset in the range 0 to nnz

colind is of length nnz and contains integers that represent a column index in the range 0 to ncols

Qualitatively these are distinct ranges and usages so it does make sense to consider having three types of data in the CSR4 format: something like OFFSET_INT_TYPE, INDEX_INT_TYPE, and then the DATA_TYPE, as follows:

OFFSET_INT_TYPE *rows_start;

OFFSET_INT_TYPE *rows_end;

INDEX_INT_TYPE *colind;

DATA_TYPE *values;

Your desire to use 8 byte integers for rows_start and rows_end but 4 byte integers for colind seems consistent with this desire to reduce the memory footprint. Did I understand your intent correctly?

However, this complicates things somewhat in the interfaces (the growth of the number of interfaces and size of the library to contain all the distinct implementations is not insignificant) and we as oneMKL decided a long time ago to not distinguish between the two types of integers in our IE Sparse BLAS C and Fortran interfaces.

Additionally, this can further complicate matters when you start considering sparse matrix - sparse matrix multiplication where the INDEX_INT_TYPE and OFFSET_INT_TYPE integer sizes might be incompatible between the two matrices, it would require some finesse and very clear rules on how the output sparse matrix should be created, filled and used.

Thus you must unfortunately pick a single integer size (based on linking to LP64 or ILP64 and using MKL_INT) for using our oneMKL APIs.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi,

Reminder:

Has the solution provided helped? Is your issue resolved? Kindly let us know if we could close this thread at our end.

Best Regards,

Shanmukh.SS

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi,

We assume that your issue is resolved. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Best Regards,

Shanmukh.SS

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page