C Wrapper to LAPACK

1. by Rémi Delmas supervised by Julien Langou C Wrapper to LAPACK

2. Summary Why a wrapper for C to LAPACK? Objectives Choices and problems Testing the wrapper

3. 1. Why a wrapper? There is a demand for it. It has already done for BLAS (CBLAS Legacy) It has already be done (CLAPACK, ATLAS, IMSL), but none of these solutions is perfect. Those are either : Non-portable, Non-optimised, Not nice, interface-wise, Non-free. Move the burden of calling LAPACK functions from the user to the developper. The C user does not want to mess with 2 compilers. Just give him the wrapper library and he is ready to go.

4. 2. Objectives Be portable It has to work on all machines where LAPACK runs, and on top of any LAPACK dist. and there is a C compiler. Be automatically generated (as much as possible, at least) To avoid the need of a maintainer. Implement a “nice” user interface Again, for the user comfort. Avoid adress passing where it is not mandatory.

5. 3. Choices and problems Plans for the wrapper, first outline. What we would have liked to do : LAPACK (fortran) LAPACK wrapper (C) calling program (C) main() lapack_dgesv() lapack_dlange() dgesv() dlange()

6. 3. Choices and problems Portability LOGICAL, INTEGER and CHARACTER are cast by default, but the user is allowed to use #defines to control the data representation. When the user uses the default setting, not loss in performance (only 1 more function call) compared to directly calling LAPACK routines. When the user defines its own settings, convertion has to be done. => loss of performance due to copy (array of integer mainly, some arrays of logicals, very few character strings). Higher memory consumption, too, because of allocation local to the function (order ~N). It could have been possible to ask for the user to give directly the data in the fortran representation... but again, one of the goals is the use for the user. The price is a small loss in performance.

7. 3. Choices and problems Portability : A choice was made to follow the CBLAS Legacy guidelines (presented in a very well-written paper) CHARACTER*1 (eg JOBZ, UPLO, etc.) are now enums : More clear for the user Mistakes are detected at compilation time Complex are cast as void*. Call to fortran functions depend on the compiler. => added #defines to support compilers that add an underscore or not, that use only uppercase, etc. Functions returning a value cannot be called directly from C. => Added a level of wrapping.

8. 3. Choices and problems Plans for the wrapper, second outline. Be portable. calling program (C) main() LAPACK (fortran) Function wrapper (fortran) LAPACK wrapper (C) dlangesub() lapack_dgesv() lapack_dlange() dgesv() dlange()

9. 3. Choices and problems Automatic generation Used David Bindel's awk script to parse the LAPACK comments to extract useful information on the functions and their parameters. This information is written to a file as pseudo-code. Then a perl-script parses this file to generate the actual wrapper source. Enforce “nice” lapack comment. If comments are not as they should be, the parser fails. => Many many LAPACK comments were debuged this way (580 lines on 359 routines changed). The 2-level parsing allows for easily writing wrappers in other langages.

10. 3. Choices and problems Enforcing LAPACK comments : If the norm is not respected, the script will fail, or worse, give false results. order of appereance is important, it must be the same than in the prototype lines begin with the variable name (input) (output) (input/output) (input or output) mandatory type in upper case if array, put the word “array” somewhere on the line, along with the dimension between (). everything must be be on one line character of size 1 are noted character*1

11. 4. Testing Two ways to test. The easiest one : unwrap the wrapper ;) to allow for the testing suite provided in the LAPACK package to call the wrapper. Problem : when a LAPACK function calls a LAPACK function, that call does not go through the wrapper (eg, dgesv will be tested but not dgetrf or dgetrs) => Only the drivers are tested. The “hard” one : Change all LAPACK functions so that the internal calls are done through the wrapper.

12. 4. Testing Testing wrapper (C) Function testing wrapper (fortran) LAPACK testing (Fortran) fdlange() (void function) cdlange() (function) call cdlange LAPACK (fortran) Function wrapper (fortran) LAPACK wrapper (C) dlangesub() (subroutine) dgesv() dlange() (function) lapack_dgesv() lapack_dlange() (double function)

13. 4. Testing Problem with first testing : only drivers are tested. lapack_dgesv lapack_dgetrf cdgesv cdgetrf dgesv dgetrf Testing

14. 4. Testing Solution :hack lapack so that call to aux routines go through the wrapper. lapack_dgesv lapack_dgetrf cdgesv cdgetrf dgesv dgetrf Testing

15. 4. Testing Some functions were awful. Bestiary : Size of array that depend on other parameters (like a char)... Size of array that depends on the result of some other function (how I am supposed to know that size?)... Some inconsistensies in the CHARACTER*1 parameters : In *ggsvd, JOBU = 'U' or 'N' JOBV = 'V' or 'N' JOBQ = 'Q' or 'N' .... but they all have the same role ! Function pointers... Differenciation of enums is based only on the parameter name. But JOB may have many meanings... Lots of hacks in the script... Places were a character would be needed, but an integer is used.

16. 4. Testing Performances : Timing was not done, but for default settings the execution time is more or less the same. The copy is a problem (cpu- and memory-wise), but we found no way to correct that.

17. Conclusion Complete automatic generation is an utopia, but we came close enough (thanks to some hacks...). Only 18 functions had to be done “by hand”. A lot of the development time was spent debugging LAPACK comments. A norm should be decided and clearly stated. We now have a working, portable and efficient C wrapper. Webpage : http://icl.cs.utk.edu/~delmas