libflame version 4.0 announced
Tue Feb 16 23:36:00 GMT 2010
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
(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
I'm not trying to be super-critical. But if we are seriously
considering this thing, then no stone will be left un-turned.
-------- Original Message --------
Subject: libflame version 4.0 announced
Date: Sun, 14 Feb 2010 00:15:04 -0600
From: Rhys Ulerich <email@example.com>
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...
More information about the Gsl-discuss