This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |