From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5567 invoked by alias); 16 Feb 2010 23:36:23 -0000 Received: (qmail 5557 invoked by uid 22791); 16 Feb 2010 23:36:22 -0000 X-SWARE-Spam-Status: No, hits=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint1.lanl.gov (HELO proofpoint1.lanl.gov) (204.121.3.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Feb 2010 23:36:17 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id o1GNaF11016132 for ; Tue, 16 Feb 2010 16:36:15 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 117FC24110C for ; Tue, 16 Feb 2010 16:36:15 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 0FC277D0044 for ; Tue, 16 Feb 2010 16:36:15 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id EA63B7D0042 for ; Tue, 16 Feb 2010 16:36:14 -0700 (MST) Subject: Re: libflame version 4.0 announced From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: <4B3F0184.2030505@iki.fi> References: <4B3F0184.2030505@iki.fi> Content-Type: text/plain Date: Tue, 16 Feb 2010 23:36:00 -0000 Message-Id: <1266363451.8015.153.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-02-16_08:2010-02-06,2010-02-16,2010-02-16 signatures=0 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 X-SW-Source: 2010-q1/txt/msg00021.txt.bz2 I spent a little time looking at the libflame manual. I have some questions; maybe somebody knows the answers. (1) The library requires FLA_Init() and FLA_Finalize(). I wonder what library-level data is initialized and how this interacts with multi-threading. It looks like it is meant to work ok with threads, but there is a build switch (--enable-multithreading) which makes me wonder what is going on. I don't like any kind of hidden state, and I really don't like hidden global state. (2) The LAPACK-like coverage seems reasonable. But I am not a good judge of this. How much LAPACK functionality is covered in this latest release? Obviously all the banded-matrix stuff is out, since libflame does nothing with banded matrices. But how complete is it regarding core functionality? (3) The separation of the metadata (FLA_Obj) and the data buffer is good. At least this means that a wrapper implementation (say C++) can use any allocation scheme it likes for the buffer. I'm not sure about FLA_Obj itself. From the code examples, it appears that FLA_Obj is stack friendly. But I can't be sure without looking at the headers. So I guess I can answer this question myself... but I'm tired now. (4) According to the manual, libflame calls abort() when it encounters a problem. As I have discussed before, this is brain-damaged. It makes it hard for other library developers (us) to integrate their thing into an existing error-handling system. They seem to admit it is a problem, but it's probably a low priority for them. How can we integrate this? (5) There are many configuration/build options. Is it feasible to build and deploy several different versions (with and without SuperMatrix, etc), from which a selection can be made at link time, requiring no source-level changes in client code? Some random comments: (a) I'm not sure what it would mean to "use libflame under gsl-2.0", as mentioned below. We need to think about ways to insulate ourselves from any specific project, while still allowing it to be used transparently. (b) libflame does not provide BLAS functionality, it requires an external BLAS. This is good, since people want to use special optimized versions for their architectures. But it also means we have the same problem as with GSL: detecting and linking against an appropriate BLAS, and dealing with its possible absence. It would be better if we could eliminate gslcblas once and for all, or at least factor it out of the main release somehow. (c) In the libflame world, it looks like scalars are themselves instances of 'FLA_Obj'. Ok, I can see the logical coherence in this, but it seems like it could be very inconvenient at times. (d) There are several places where the API assumes C stdio. It looks like some of these uses are internal (like FLA_Print_message being used for error messages). This is brain-damaged, since it makes it harder to integrate into other environments (i.e. C++) where C stdio is not appropriate. It's ok to have such "convenience" functions in the API, but they should not be used internally. (e) The autotools build looks somewhat annoying. I'm really tired of autotools. Obviously, the same is true of GSL. (f) The API has both capitals and underscores, the worst choice of all. Seemingly trivial, but it makes me queasy. Will people never learn? I'm not trying to be super-critical. But if we are seriously considering this thing, then no stone will be left un-turned. -- G. Jungman -------- Original Message -------- Subject: libflame version 4.0 announced Date: Sun, 14 Feb 2010 00:15:04 -0600 From: Rhys Ulerich To: gsl-discuss@sourceware.org Hi all, There was some talk several months back on using libflame underneath GSL 2.0. libflame 4.0 was announced today, and it both includes row-major support and eliminates their lingering Fortran/LAPACK dependencies. The release announcement follows... - Rhys