int or long int?

[olecram]

I see in the documentation that MKL functions use "int" arguments to specify sizes. Even Intel compiler's _mm_malloc() seems to use "int" to specify sizes.

My question is, how does MKL deal with arrays larger than the size limit imposed by "int" on EM64T?

[TimP]

This problem is not unique to MKL; it is a common problem in 64-bit operating systems which use 32-bit default integers. When calling BLAS functions from code which is using long integers, it is necessary to make a default integer copy of each argument, losing the ability to specify larger array sizes.

Of course, the maximum array sizes ought to be significantly bigger than what could be allocated with a crippled version of malloc which accepts only int parameters. In my opinion, it is a bug if _mm_malloc() accepts only (int) for its first parameter, and you would then want to avoid it on the 64-bit OS. As malloc() on a 64-bit OS is required to accept (size_t) argument, and return a 16-byte aligned region, it does appear that the _mm_malloc() is less useful there. _mm_malloc() on the 32-bit system is a work-around for the problem that traditional 32-bit malloc() doesn't meet the requirement of standard C, that the alignment must be suitable for all objects defined in C. The 64-bit ABI corrects that.
Apparently, _mm_malloc() is not intended to scale into 64-bit environment.
When you use MKL, not only is standard malloc() available, there is also kmp_malloc(), and additional specialized versions for cluster OMP, which have (size_t) parameter.

[Intel_C_Intel]

There are really two separate issues. The one is: How large an integer value do I need? The second is: How much memory do I need to address?

MKL currently uses what is known as the LP64 model in which pointers are 64-bits but integers are 32-bits. From a user's perspective it doesn't matter what we do inside the library as long as we can access all the memory we need to.

In calling a function the integers are 32-bits so the largest dimension is about 2 billion. So the dimensions of arrays cannot exceed that size. But that's an enormous dimension! Inside MKL, where ever we do our own memory management we have to use 64-bit integers in address computation.

What if you have compiled your program with 64-bit integers and call MKL with it's 32-bit integers? As long as none of your sizes exceed 31 bits (remember, that 32nd bit is a sign bit for MKL), nothing, because everything is little endian.

If we used 64-bit integers and 64-bit pointers this would be the ILP-64 model. We are developing a version of MKL for the Itanium processors that supports this model. But even there, there will be some 32-bit integers, namely, in calls to the threading library (libguide) and MPI. There have been several customers over time who have requested this version of the library and we are responding to these requests.