This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: GSL v2.0 discussion
- From: Patrick Alken <patrick dot alken at Colorado dot EDU>
- To: "gsl-discuss at sourceware dot org" <gsl-discuss at sourceware dot org>
- Date: Fri, 04 Apr 2014 14:52:55 -0600
- Subject: Re: GSL v2.0 discussion
- Authentication-results: sourceware.org; auth=none
- References: <533EE354 dot 4050204 at colorado dot edu> <533EE585 dot 40301 at colorado dot edu> <CAKDqugQuLsj71+PbEYM8RUhrHpTZKiEed0svWbaDK=kFv0Yp4g at mail dot gmail dot com>
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