public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: GSL containers (switched sparse format to binary trees)
Date: Fri, 02 May 2014 01:48:00 -0000	[thread overview]
Message-ID: <5362F944.9090408@lanl.gov> (raw)
In-Reply-To: <5362D6E1.5080605@lanl.gov>


Here is an example of the sort of thing that
troubles me.

http://stackoverflow.com/questions/15988836/better-memory-management-for-gsl-gsl-vector

It is a reasonable discussion of exactly the sort of
use case that keeps coming up. A couple independent
issues are raised here.

First is the question of allocation/deallocation overhead,
which I think is the smaller of the issues, although it is
important for people who need a lot of small vectors.
This is the standard example justifying use of a
custom pool allocator.

Someone suggested using a single large gsl_block, effectively
using that as a pool. This is not stupid, although it only
works for some kinds of codes, where the allocation and
hand-off of memory can be done in a central place, like
at application startup time or something. At least that
is how I think of that usage case. It appears that the
OP was in one of the more de-centralized situations,
where this would not work nicely.

Ignore the associated comment about the "price you pay"
when using a language without built-in garbage collection.
Garbage collection (or lack thereof) is not the problem.
But that is a separate discussion. See Stroustrup's comments
about the correct use of the heap, in various talks lately.

Second is the issue of value-semantics for containers. This
is very tricky, possibly the deepest problem of all. Notice
how the OP created a custom allocation function which returns
a gsl_vector by value, not by pointer. That may or may not be
the right choice for him, but it is interesting that he chose
to do it that way.

Value-semantics is probably the most important issue for
container design, probably for several reasons. At the
top of my list is the desire to get things onto the
stack whenever possible. The fact that gsl_vector
(the struct itself, not the data) is off the heap
is an annoyance.

And it's the kind of annoyance that may be no problem
for some people and a show-stopper for others. It's
too hard to tell in advance, since it is too hard
to predict how modern hardware will treat your
code. Stack-based computation helps, and linear
traversal of data structures helps a lot, because
the pre-fetcher will bring in the pages you need
before you actually need them, as long as it can
predict which ones are needed next.

The heap tends to gum everything up on modern architectures,
unless you are careful. And taking that kind of care may
require taking over the alloc/free control from the
standard library.


So, the specific point raised by this value-semantics
business, and its effect on heap confusion, is this:
what to do about the fact that the GSL container
structs are always off the heap?


The final post in this short thread may hit the nail on
the head. What he suggests is what I almost always do:
use C++ containers and C++ code as much as possible,
and bang the pointers into GSL functions when necessary.
A bit sad.


  reply	other threads:[~2014-05-02  1:48 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                 ` Gerard Jungman [this message]
2014-05-02  1:56                   ` GSL containers (switched sparse format to binary trees) 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
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=5362F944.9090408@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).