[IPOL discuss] [LATE] Re: Clapack and cblas libraries interfacing
Nicolas Limare
nicolas.limare at cmla.ens-cachan.fr
Fri Oct 31 08:00:30 CET 2014
(Answering a VERY old mail from Tristan)
Hi,
I recently worked with BLAS, and I wanted a code that works well with
multiple BLAS implementation (Netlib, ATLAS, OpenBLAS, GSL and MKL). I
try to answer from this experience in this (long) message.
In short
* BLAS for C/C++: use the CBLAS interface as defined in cblas.h (see
http://www.netlib.org/blas/#_cblas), with any standard-compliant
library (Netlib, ATLAS, OpenBLAS, GSL, MKL)
* LAPACK for C/C++: "CLAPACK" does not exist as a native C interface
to LAPACK; declare yourself the extern Fortran functions and
link with the Fortran binary libraries; LAPACKE should become usable
later
* IPOL guidelines must be corrected: "CLAPACK" is misleading,
replace with LAPACK (Fortran/C Interface) and LAPACKE (C Interface)
* IPOL servers must be upgraded to get recent versions of these
libraries, including liblapacke
* now you can also use the GSL functions, but then you can not switch
to other implementations later without changing the source code
8<----------8<----------8<----------8<----------8<----------8<----------
> I would like to share my recent experience about linking cblas and
> clapack librairies (two of the authorized libraries in the
> guidelines 1.00) with a IPOL program, because this leads some
> remarks and questions.
> [...]
> - Is there a reference version of Clapack, Cblas defined in the IPOL
> guidelines ?
"BLAS" refers to a Fortran interface, defined on
http://www.netlib.org/blas/. There are many BLAS implementations,
programmed in Fortran or not. The only thing that matters is that a
BLAS library can be called from a Fortran code as defined by the BLAS
convention.
For C/C++ code, one has two options: use the Fortran interface,
adapted to the C language (both are very close and compatible), or use
an interface designed for C code: the "CBLAS" interface, defined on
http://www.netlib.org/blas/#_cblas.
BLAS Fortran interface for C code looks like
call dgemm_(char * transa, char * transb, int * m, int * n, int * k,
double * alpha, doucle * a, int * lda, double * b, int * ldb,
double * beta, double * c, int * ldc);
CBLAS C interface looks like
void cblas_dgemm(const enum CBLAS_ORDER Order, const enum CBLAS_TRANSPOSE TransA,
const enum CBLAS_TRANSPOSE TransB, const int M, const int N,
const int K, const double alpha, const double *A,
const int lda, const double *B, const int ldb,
const double beta, double *C, const int ldc);
CBLAS interface is better. "consts" qualifiers protect read-only
variables, "enum" types protects variables with only a few allowed
values. If you use BLAS from a C code, there is no reason to use the
Fortran interface. The CBLAS interface is provided by every correct
BLAS library. The interface declaration (cblas.h) is provided with
these libraries. Any correct declaration of the interface should be
usable.
To use them, #include <cblas.h> from you C code (using any cblas.h
file) then link with the library. A makefile fragment is attached to
this message, showing how to choose at compilation time which library
you link with (used and tests with sgemm on Linux only, with Netlib,
ATLAS, OpenBLAS, GSL and MKL).
> In addition, the installation from sources, of the (2) and (3) librairies
> is quiet subtile and tricky (gfortran compilers, f2c ...) and needs
> certainly more time than a final user of an IPOL program should expect.
No one should be required to install a BLAS or LAPACK library from
source. Binary packages exist for many platforms and should be
usable. Perfomance is important, so a binary library optimized for
your CPU is better. Finally, there is no need for f2c translation. The
implementation language of the library (Fortran or C) doesn't matter,
we only need a declaration of the interface compatible with C code, and
it is cblas.h.
> There are currently at least 3 versions of C prototypes for CBLAS and
> CLAPACK, linking the C functions with the Fortran binaries:
>
> (1) the version from ATLAS, clapack.h with only few prototypes
> (2) the version from sources lapack 3.2.1, clapack.h with all prototypes clapack_****()
> (3) the version from sources lapack 3.4.0, lapacke.h with all prototypes LAPACKE_****()
For LAPACK, it is more confusing, I am not 100% sure I got it
right. Please someone correct me if needed.
"LAPACK" is a Fortran interface, defined on
http://www.netlib.org/lapack/. There are many LAPACK implementations,
and they usually call a BLAS library for efficient low-level matrix
manipulations. Here again, if you code in Fortran, there is no
problem: you can use any implementation that follows the standard
LAPACK interface definition.
Like any Fortran code, it can be used from C using the native Fortran
interface adapted to C (same as BLAS); it is a low-level interface
with few controls of the code correctness (same as BLAS), but it
should work with any correct LAPACK library. For a while, this was the
only C interface to LAPACK. There is an automatic translation of
Fortran LAPACK to C, called CLAPACK (http://www.netlib.org/clapack/),
which provides the same C interface as the one usable with the Fortran
implementation:
void dsyevd_(char *jobz, char *uplo, int *n, double * a, int *lda,
double *w, double *work, int *lwork, int *iwork, int *liwork, int *info);
For a C code, calling the Fortran LAPACK library or the C CLAPACK
library makes no difference. We only need a correct declaration of the
functions available in the (binary) library.
Unfortunately, declaration files provided by LAPACK 3.2 (clapack.h),
CLAPACK (clapack.h), and MKL (mkl_lapack.h) have small differences in
how they are used. Moreover, ATLAS does not provide a declaration of
its Fortran functions for C, and the clapack.h file in this library
contains something else, an interface to C functions.
A solution is to declare yourself the extern Fortran functions you
want to in your own lapack.h, then link with any LAPACK
library. LAPACK Fortran interface and C/Fortran binary interfaces are
well defined, so it should work well and for a long time.
LAPACKE is to LAPACK what CBLAS is to C: a C interface, well adapted
to anyone coding in C. But it was only proposed in 2008 and adopted in
2010, so it is not yet implemented by every LAPACK library. For
example, I do not find LAPACKE in ATLAS. The Debian package liblapacke
seems to be a LAPACKE implementation, calling LAPACK behind, so it
sould be usable with any LAPACK library as a backend, but it must be
tested. And it is not installable on IPOL servers, they must be
upgraded first.
> - What about the GSL library, which owns more stable prototypes (it is
> natively written in standard C and does not need Fortran
> conversions). Is its integration planned for the next guidelines as
> a possible alternative as external library ?
GSL has been added to the list of libraries allowd for IPOL. The
gsl_cblas.h interface is identical to cblas.h; if you use it, you can
choose later to link with any other BLAS library. The gsl_blas.h
interface use the GSL syntax and GSL objects (vectors, arrays); it can
be more convenient to use it if your code uses other parts of the GSL,
but then you can not switch to another BLAS library. Both options are
OK per IPOL guidelines.
For higer-level linear algebra, I thing GSL implements its own
routines. You can use GSL instead of LAPACK, but it is different
interface and I think you can not benefit from high-performance BLAS
libraries.
By the way (if anyone reads until there...), from my tests on a
recent machine with 2x8 cores and AVX vector instructions, MKL is a
lot faster than any other BLAS implementation, by a large
difference. And Eigen is slooow.
--
Nicolas LIMARE
http://nicolas.limare.net/ pgp:0xFA423F4F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20141031/a1cb24a8/attachment.pgp>
More information about the discuss
mailing list