Re: GSL v2.0 discussion

[Patrick Alken <patrick.alken@Colorado.EDU>]

On 04/04/2014 02:30 PM, Rhys Ulerich wrote:
> Hi Patrick,
>
>    -- Merging the two B-spline workspaces into one
This is already done - bspline_deriv_workspace is gone and everything is 
now in bspline_workspace
>
> On the libflame/LAPACK question you raise, and out-of-order response
> to 5 before 1 though 4....
>
>> 5. Is there a strong preference for doing wrappers for both lapack and
>> flame? Should we only interface to lapack, due to the difficulties with
>> flame (global state, abort() error handling)? Should we only interface to
>> flame due to its more modern design?
> Maintaining two sets of linear algebra backends is error prone and
> will stretch our already thin time to hack on GSL.  We might take an
> intermediate approach and target
> http://www.netlib.org/lapack/lapacke.html.  That'll solve C-to-Fortran
> linkage hell for legacy LAPACK (assuming vendors support it) and
> aiming for the standard-ish API follows the GSL precedent of writing
> to the CBLAS API.  As libflame has a LAPACK-compatibility layer
> ("lapack2flame"), any LAPACKE "shim" permitting talking to a legacy
> LAPACK would also permit talking to a fairly large subset of libflame.
I must say I do like the idea of doing a lapack interface only, and then 
using the lapack2flame layer for libflame. Lapack is still the standard 
library, and many research groups continue to actively contribute code 
to lapack. Also last time I checked, libflame hasn't implemented the 
nonsymmetric eigenvalue solver. Lapack has a very sophisticated 
algorithm for this which would probably be a nightmare to port over to C 
(I actually looked into this once).

I need to look into whether lapack2flame accepts LAPACKE calls or just 
LAPACK calls (I don't see any reference to LAPACKE in the flame user 
manual). In any case, lapack is usually installed by default on many 
systems, whereas lapacke is probably not, so it may be worth supporting 
lapack instead.

 > Assuming success with that LAPACKE idea and a good driving use case, 
we could marry GSL more closely with libflame down the road.
>> 1. Should we try to add lapack/flame interfaces for the 2.0 release or wait
>> until 3.0? I personally probably won't have a lot of time to work on this
>> for several months.
> Ditto here on the time crunch for a few months (stupid overdue
> thesis).  I'd aim for LAPACKE in 2.0 and, if needed, tighter libflame
> in 3.0.
>
>> 2. Is it better to select gsllinalg/lapack/flame at compile time or link
>> time?
> Link time, and presumably an invisible thing for us with LAPACKE
> provided that the Autoconf infrastructure can find something sensible
> for 'make check'

One possible pain for link-time support is that it would break many 
existing makefiles, since users would need to add an additional 
-lgsllinalg or -lgsllapack to all GSL programs. This may not be such a 
problem but its worth thinking about.

>
>> 3. Whats the best way to handle the memory workspace requirements (add
>> _alloc functions to all gsl_linalg routines or dynamic allocation)?
> Use of high-level LAPACKE claims to handle workspace allocation.  If
> it becomes performance critical somewhere, we could manage it
> internally and use the medium-level API along with explicit
> management.
>
>> 4. What should we do about error handling in libflame? Just accept the
>> abort() behavior?
> If libflame's LAPACK-compatibility does not include proper error
> handling and just calls abort(), well, that would be their problem to
> fix if they claim compatibility.
>
> Once upon a time I got Brian's permission to yank the gsl_error
> infrastructure for libflame and submitted a patch.  That can be dug up
> if they want/need it.
>
> - Rhys