Re: libflame version 4.0 announced

[Gerard Jungman <jungman at lanl dot gov>]

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 <rhys.ulerich@gmail.com>
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