|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Patrick Kowalzick (patrick.kowalzick_at_[hidden])
Date: 2005-01-18 07:08:26
Dear Toon,
I hope I do not miss the point, but I do not really get the reason why to
distinguish so many storage_types (heap/stack/disk/...). So I try to
summarize what I understood (but as well regarding matrices and only dense
cases):
To make algorithms work, we need only a very slim interface for cointainers
with constructors, element access and size functions. But to make the
functions efficient and fast we need more information.
IMO the most important points for the storage concepts are:
1.) How are the elements stored ?
2.) How is the data initialized ?
3.) Is the vector resizable ?
to 1.)
For an effective algorithm it is not necessary that the data is "globaly"
consecutive. It might be enough that parts of the data are "localy"
consecutive. E.g. two matrices which are stored in several vectors (rows or
columns) can be added very fast iterating along the vectors but not across
the vectors (but only due to the cache). If the storage order (row_order or
column_order) in both matrices is different the algorithm shall run along
the vectors of the one and try to cache the corresponding vector of the
other matrix (for our computer architectures). The problem here depends more
on the row/colun_order than on "global" consecutive memory. Perhaps there
might be a flag "force_caching" for disk/compund, but not an own concept?
Anyway I think that row_order and column_order is not very generic if
sometime someone gets the idea to adopt the concepts to tensors (OT, but
same is interessting for element access and size functions).
IMO the "Interaction with BLAS and LAPACK" is a special case (indeed very
important) and does not only need consecutive_in_memory but also
column_order for matrices.
to 2.)
If data is initialized (constructor or resize) or not, might be sensitive to
performance (if I remember right the discussions we had in the uBLAS ML). If
a goal of GLAS is to give the user the freedom to chose a cointainer (via
traits/adapters?) there shall be an information about this or it must be
defined what happens. Perhaps there might be a difference between the
constructors and resize? Or a storage type allows both, initialized or
not-initialized values?
Shall GLAS be able to handle easily different containers? The first coming
in my mind are std::vector, boost::array and boost::multi_array.
to 3.)
IMO, only if there is an information if a vector is resizable there might
exist a compile-time check if an addition between two not-resizable vectors
is possible. I do not have an example (and it might not exist with
expressions), but I can also imagine that some algorithms might need resize
and can not always work with a constructor.
I think I have to think about an example, when an algorithm needs to know
where (heap/stack/disk,...) the data is stored.
Regards,
Patrick