From: Patrick Alken <patrick.alken@Colorado.EDU>
To: gsl-discuss@sourceware.org
Subject: Re: GSL containers (switched sparse format to binary trees)
Date: Fri, 02 May 2014 15:02:00 -0000 [thread overview]
Message-ID: <5363B395.5060101@colorado.edu> (raw)
In-Reply-To: <5362FB2A.7090608@lanl.gov>
This particular thread seems to be more about dynamic allocations of
gsl_vector inside the multimin routines - I wasn't aware that was
happening but in theory it should be possible to rewrite things so there
are no dynamic allocations.
The first thread you linked seems to have a legitimate reason to reduce
the malloc calls for gsl_vector, since he's allocating a large number of
small vectors it seems.
Anyway, Gerard, you have a good grasp of the various issues and what
needs to be done about it - would you be interested in taking the lead
on this and designing a nice API for user-defined alloc functions?
Patrick
On 05/01/2014 07:55 PM, Gerard Jungman wrote:
> As before, I apologize for the flood of messages.
> But I figure better a few shorter messages than
> one long message with multiple sub-topics.
>
> Here is another discussion that I found interesting:
>
> http://comments.gmane.org/gmane.comp.lib.gsl.general/4385
>
> As usual, the details could be debated. But I found the
> following quote to be very telling:
>
> "Rhys, I did try to use views. They do not help because the
> gsl routines allocate vectors internally and there is not
> much that I can do about it... except for maybe hacking
> gsl and changing gsl_vector_alloc myself."
>
> People seem to be led to this conclusion from multiple
> directions.
>
> Another choice quote:
>
> "The other issue is: the implementation of gsl_vector just
> seems inefficient to me. Looking at the code, it seems like
> a single vector requires 3 calls to malloc and free (one for
> the data, one for the gsl_block, and one for the gsl_vector
> itself). The manual states that the block is there for
> "consistency", and I can see how memory management becomes
> easier with it. But it seems to be a case of generality at
> the expense of performance. Also, the stride and the owner
> flag are part of the gsl_vector object to make it work with
> gsl_views, but then people who never need views pay the
> performance price anyway."
>
>
>
next prev parent reply other threads:[~2014-05-02 15:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 1:32 switched sparse format to binary trees Patrick Alken
2014-04-28 22:35 ` Gerard Jungman
2014-04-29 1:13 ` Patrick Alken
2014-04-29 8:40 ` Frank Reininghaus
2014-04-29 19:15 ` Gerard Jungman
2014-04-29 19:52 ` Patrick Alken
2014-04-29 22:07 ` Gerard Jungman
2014-05-01 18:46 ` Patrick Alken
2014-05-01 23:21 ` Gerard Jungman
2014-05-02 1:48 ` GSL containers (switched sparse format to binary trees) Gerard Jungman
2014-05-02 1:56 ` Gerard Jungman
2014-05-02 8:29 ` Rhys Ulerich
2014-05-02 8:33 ` Rhys Ulerich
2014-05-02 8:52 ` Rhys Ulerich
2014-05-02 15:02 ` Patrick Alken [this message]
2014-05-13 21:59 ` Gerard Jungman
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=5363B395.5060101@colorado.edu \
--to=patrick.alken@colorado.edu \
--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).