|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-01-20 08:27:04
Patrick Kowalzick wrote:
>>>>> 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).
>>>>
>>>>
>>>>
>>>>
>>>> True. That was also (part of) the idea behind compound_storage. But
>>>> suppose your matrix uses several vectors to store its elements, you
>>>> still want to define _where_ these vectors are stored.
>>>>
>>>> For maximum flexibility you might want to store them on the heap
>>>> (this would allow resizing, see later). But for performance reasons
>>>> you might want them on the stack. This is less flexible however
>>>> because the size is limited. When treating very large vectors that
>>>> are too big to store in memory, you will have to store (part of)
>>>> your vector in a file. _These_ kind of _optimizations_ are the most
>>>> important idea behind the storage.
>>>
>>>
>>>
>>> I do not agree, and the reasons therefor are simple: I do not see a
>>> reason to chose where to save the data except with the direct use of
>>> (simple) containers. But it is true that I do not have a reason
>>> against. So my personal conclusion is easy: I have to test a little
>>> bit and try some configurations......
>>
>>
>>
>> IIUC you don't agree that we need soth. like a storage? Don't you
>> think it would be good to be able to specify if a vector should be
>> stored on the heap or on the stack? What do you mean by 'simple
>> container' in the above paragraph?
>
>
> No, I believe it is very important to have the choice _where_ to store
> the data, but this is a users view. I am not sure that an algorithm
> (developer) needs to know _where_ the data is stored, but the
> algorithm must have the ability to work efficient and needs the _how_.
>
> An orthogonal design would imply for me, that a user can use any
> container he likes (if adopted a lit to cary informations needed about
> the structure) including boost::array (stack), std::vector (ok,
> inefficient constructing) or a wrapper for an easy heap based array.
>
> But, as long as I m not familiar with implementation designs I have to
> test a little bit before, to make common implementation errors :).
>
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.
Karl