From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22463 invoked by alias); 4 Apr 2014 20:52:59 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 22449 invoked by uid 89); 4 Apr 2014 20:52:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: ipmx6.colorado.edu Received: from ipmx6.colorado.edu (HELO ipmx6.colorado.edu) (128.138.128.246) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Apr 2014 20:52:57 +0000 From: Patrick Alken Received: from bonanza.ngdc.noaa.gov ([140.172.179.41]) by smtp.colorado.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2014 14:52:55 -0600 Message-ID: <533F1BA7.5020003@colorado.edu> Date: Fri, 04 Apr 2014 20:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "gsl-discuss@sourceware.org" Subject: Re: GSL v2.0 discussion References: <533EE354.4050204@colorado.edu> <533EE585.40301@colorado.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-q2/txt/msg00009.txt.bz2 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