C Wrapper to LAPACK

by Rémi Delmas

supervised by Julien Langou

03/13/06 14:09 2

Summary

1.Why a wrapper for C to LAPACK?

2.Objectives

3.Choices and problems

4.Testing the wrapper

03/13/06 14:09 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.

03/13/06 14:09 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.

03/13/06 14:09 5

3. Choices and problems

● Plans for the wrapper, first outline. What we would have liked to do :

LAPACK

(fortran)

dgesv()dlange()

calling program(C)

main() lapack_dgesv()lapack_dlange()

LAPACK wrapper(C)

03/13/06 14:09 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.

03/13/06 14:09 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.

03/13/06 14:09 8

3. Choices and problems

● Plans for the wrapper, second outline. Be portable.

LAPACK

(fortran)

dgesv()dlange()

calling program(C)

main()

lapack_dgesv()lapack_dlange()

LAPACK wrapper(C)

Function wrapper(fortran)

dlangesub()

03/13/06 14:09 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.

03/13/06 14:09 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

03/13/06 14:09 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.

03/13/06 14:09 12

4. Testing

LAPACK

(fortran)

dgesv()dlange() (function)

LAPACK testing(Fortran)

lapack_dgesv()lapack_dlange() (double function)

LAPACK wrapper(C)

Function wrapper(fortran)

dlangesub() (subroutine)

Function testingwrapper (fortran)

cdlange() (function) call cdlange

Testing wrapper(C)

fdlange() (void function)

03/13/06 14:09 13

4. Testing

» Problem with first testing : only drivers are tested.

Testing cdgesvcdgetrf

lapack_dgesvlapack_dgetrf

dgesvdgetrf

03/13/06 14:09 14

4. Testing

» Solution :hack lapack so that call to aux routines go through the wrapper.

Testing cdgesvcdgetrf

lapack_dgesvlapack_dgetrf

dgesvdgetrf

03/13/06 14:09 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.

03/13/06 14:09 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.

03/13/06 14:09 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