[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: atlas-comm@cs.utk.edu*Subject*: 64-bit C-BLAS?*From*: Tim Davis <davis@cise.ufl.edu>*Date*: Thu, 22 Mar 2001 12:14:32 -0500*Cc*: davis@cise.ufl.edu

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, http://www.sun.com/solaris/64bit.html or http://soldc.sun.com/articles/solarisupgrade/64bit/Convert.html . See also "man dgemm" on a Sun; in the Sun Performance Library, there is a 64-bit routine: 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 INTEGER's. In the 64-bit model, long's are supposed to be used for array indices, not int's. 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. Thanks, Tim Davis http://www.cise.ufl.edu/~davis

- Prev by Date:
**memory leak in ATLAS** - Next by Date:
**MKL5.0 vs. ATLAS3.2.0 on 933Mhz PIII** - Prev by thread:
**MKL5.0 vs. ATLAS3.2.0 on 933Mhz PIII** - Next by thread:
**memory leak in ATLAS** - Index(es):