Re: libflame version 4.0 announced

[Gerard Jungman <jungman at lanl dot gov>]

On Wed, 2010-02-17 at 21:04 +0000, Brian Gough wrote:
> 
> The problems below are all fixable I am sure.

Sure, they're fixable, but the question is by whom.
I'm trying to chart a specific course for integration.

I assume we don't want to touch (fork) their code
base; that's to be avoided at almost all costs.

I just want to link against it, presumably through
some GSL-owned insulation layer, which can be
configured to point to any conforming implementation.
Similar to the BLAS wrapper layer.

But this requires some kind of interface design. With
BLAS we were lucky that a standard C interface existed
already. But it's not so clear what a "standard" LAPACK
interface would look like. It's very nice that they have
gifted us with their implementation and their interfaces
for a model. But it doesn't leave us entirely off the hook.

The other big problem is what to do with their data
structures. Obviously we need an insulation layer to
protect clients from changes in FLA_Obj and friends.


Here are some problems to be solved:

(1) Explicitly specify the data layout for buffers of underlying
    types. There is presumably only one reasonable way to do this,
    but we should be sure not to paint ourselves into a corner
    in some initially unforeseen way. Understand how it fits
    into a larger scheme involving multiarrays, etc. Make sure
    that it makes sense _across_ language barriers. This includes
    things like the complex types. What is our philosophy about
    packing complex types and can we make it language-neutral?
    Is this a solved problem yet?

(2) Decide how to map (semantically and syntactically) the
    FLAME picture of metadata to/from anything else we might
    want to expose. Do we compose our metadata objects from
    theirs (bad insulation?)? Do we transform representations
    on the fly (performance penalties?)? Is metadata hidden
    behind functional interfaces (performance again?)? Or
    is it exposed (as documented struct elements for example)?

    I am perfectly happy to accept their definitions for the
    abstract metadata. It's good to have a document (FLAME manual)
    that lays it all out explicitly. But there is still stuff to do.

(3) Design an access scheme that makes sense, i.e. no awful
    element-wise '_get' and '_set' functions. Make sure that
    GSL clients have full and free access to the data buffer,
    so that it can be manipulated directly, passed to external
    functions for element-wise processing, etc. Make sure that
    other GSL components that expect globs of data are friendly
    to these buffers and to the metadata that may be needed to
    guide access to these buffers. Also make sure no
    heap-centric-isms creep in.


These are only some things to think about. Of course, I have
some (very preliminary) opinions, but that's for later discussions.

--
G. Jungman