[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I have a question regarding the use of the C-BLAS in the LP64 model
(int's are 32 bits, long's and pointers are 64 bits).
All of the integer arguments to the cblas_* routines are int's. This
works fine in the standard ILP32 model (int's, long's, and pointers are
all 32 bits).
In the standard LP64 model, int's are limited to about 2^31 in magnitude,
but long's and pointers are 64 bits. Using int's as arguments is too
small for a 64-bit application. See, for example,
See also "man dgemm" on a Sun; in the Sun Performance Library, there is a
void dgemm_64(char transa, char transb, long m, long n, long
k, double alpha, double *a, long lda, double *b,
long ldb, double beta, double *c, long ldc);
and similar Fortran routines with INTEGER*8 arguments instead of mere
In the 64-bit model, long's are supposed to be used for array indices,
Will there be a 64-bit-aware C-BLAS that uses long integer arguments
instead of int's, and indexes its arrays internally with long's, not int's?
Say a "cblas64_*" set of routines?
Sun supports a 64-bit BLAS (dgemm_64, etc.); do other companies do the same
with their BLAS?
This is the only major impediment that I see for coming out with a 64-bit
version of my sparse solver, UMFPACK,
http://www.cise.ufl.edu/research/sparse/umfpack , which has a C-BLAS interface.
You might wonder if I would be insane enough to contemplate a matrix larger
than 2^32 by 2^32. I'm not. When using the BLAS in an unsymmetric sparse
factorization code, you can get very tall and thin (or short and squat) dense
submatrices, where just one of the dimensions m or n is larger than 2^31 (k,
in my case, is limited to a small constant in dgemm). The total problem size
could still be just a handful of GBytes (but more than 4GB), even if one of m
or n (but not both) in a call to dgemm is larger than 2^31.