(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
signature.asc
Description: Digital signature
-- IPOL - Image Processing On Line - http://ipol.im/ contact [email protected] - http://www.ipol.im/meta/contact/ news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/ announces [email protected] - http://tools.ipol.im/mm/announce/ discussions [email protected] - http://tools.ipol.im/mm/discuss/
