Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release

[Gerard Jungman <jungman@lanl.gov>]

The problem with the GSL containers is that the allocation
strategy is hard-wired into the implementation. Adding
another allocation strategy is not the answer, it just
adds to the problem.

Put another way, the real problem is that the GSL interfaces
are written in terms of gsl_vector and gsl_matrix objects,
which forces clients to carry along the allocation baggage
whenever they want to use a GSL interface.

The interfaces (every function that currently takes a
const gsl_vector * for example) should be re-written in
terms of a view type which is independent of allocation
strategies. A view type should be basically a thin
wrapper over a pointer and a length for vectors.
For multi-array objects it would be a thin wrapper
over a pointer with an addressing/indexing interface.

The current "view" types are brain-damaged because
they stand the design on its head. This is because
they were added as an afterthought to the existing
heap-allocated vector/matrix objects, at the time
when this was all being implemented. Badly done.

At the implementation level, the other main problem
is the way the types are "composed" using indirections.
This is awful and leads to the multiple allocations and
other heap-centric lossage that has been discussed
recently. Both views and full-fledged containers
should be composed in a value-centric and
stack-friendly way.

And preferably in a way that allows them to interoperate
and keep const-correctness. I believe this is all possible.

--
G. Jungman


On 11/01/2015 02:00 PM, John D Lamb wrote:
> On 26/10/15 15:13, Patrick Alken wrote:
>>> Yes. I’d be happy to look at redesign of the GSL containers. What’s
>>> needed?
>>>
>>
>> There was a discussion on gsl-discuss some time back, see:
>>
>> https://www.sourceware.org/ml/gsl-discuss/2014-q2/
>>
>> Gerard may have already done some work on this, or have some ideas on a
>> good starting point, so I suggest getting in touch with him too (cc'd).
>
>
> I’d forgotten the detail of that discussion.
>
> I can think of a way to change the gsl block/vector/matrix alloc 
> functions to be more efficient. In essence it is a pool allocator.
> It would keep a record, for each power k of two up to some limit n, of 
> the number of blocks allocated for sizes 2^k to 2^{k+1} together with 
> a capacity (also a power of two) for blocks of that range. These would 
> form linked lists of allocated and unallocated blocks. Given a request 
> for a new block, if an unallocated one was available, it would be 
> allocated. Otherwise the capacity would be doubled. When a block is 
> freed, memory is only deallocated if no more than a quarter of 
> capacity is used or if no blocks are used.
>
> This idea needs more input.
>
> I can’t think of a good way to create gsl_vectors and the like in 
> stack memory. Of course, it is always possible to create a struct and 
> initialise it.
>
> I also don’t know of a good, easy solution to the problem of constness.
>