|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Patrick Kowalzick (patrick.kowalzick_at_[hidden])
Date: 2005-01-25 05:46:59
Dear Karl,
I tried to think a lit again :).
>>> One of the reasons we want to have this discussion now is that
>>> algorithms may be (and usually are) different for different forms of
>>> storage. For example, when data are stored on disk or distributed on a
>>> network, the algorithms change. So, algorithms may have to know how data
>>> are stored in order to optimize data access.
>>
>>
>> Do you have an example for that?
>>
>> E.g. when a matrix is too big to fit in memory, it is not the algorithm
>> which selects to save parts of the data on disk. IMO it is the operating
>> system which swaps out data.
>
>
> Well, it is usually more efficient to 'swap' yourself. It is used in
> out-of-core linear system solvers for example.
When it is more efficient to swap yourself, you need IMO more information
_about_ the storage you use to write a generic algorithm. This means you
need information about the capacity and the speed (which may vary with the
capacity). Otherwise you are not able to write the most effective algorithm.
Even if you knew this, it is IMHO still a question of an orthogonal design
to not use concepts of the container until it is necessary. E.g. I would
prefer explicit usage of a container for temporaries (this is about what we
are talking?) than using a concecpt:
I would prefer
disk_matrix<...> temporary = ....
against
matrix<....,disk_storage> temporary = ...
Furthermore a concept does not describe the efficiency of the container
implementation. Take a look at the different kinds of sparse matrix where
the performance is dependant of the matrix structure.
Regards,
Patrick