From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release
Date: Tue, 03 Nov 2015 20:56:00 -0000 [thread overview]
Message-ID: <56391F62.2030103@lanl.gov> (raw)
In-Reply-To: <56367D54.1040302@johndlamb.net>
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.
>
next prev parent reply other threads:[~2015-11-03 20:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56293649.8010009@colorado.edu>
[not found] ` <562BA530.7090508@johndlamb.net>
[not found] ` <562E432D.9050002@colorado.edu>
2015-11-01 21:00 ` John D Lamb
2015-11-03 20:56 ` Gerard Jungman [this message]
2015-11-04 20:35 ` Patrick Alken
2015-11-04 23:06 ` Gerard Jungman
2015-11-04 23:16 ` Patrick Alken
[not found] ` <563AB455.1020706@lanl.gov>
2015-11-05 4:41 ` Patrick Alken
2015-11-07 14:09 ` John D Lamb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56391F62.2030103@lanl.gov \
--to=jungman@lanl.gov \
--cc=gsl-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).