This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: GSL containers (switched sparse format to binary trees)
- From: Gerard Jungman <jungman at lanl dot gov>
- To: gsl-discuss at sourceware dot org
- Date: Thu, 01 May 2014 19:55:54 -0600
- Subject: Re: GSL containers (switched sparse format to binary trees)
- Authentication-results: sourceware.org; auth=none
- References: <535DAFC0 dot 8090402 at colorado dot edu> <535ED7A5 dot 7020309 at lanl dot gov> <535EFCA5 dot 8050807 at colorado dot edu> <CAFoZWWg9ENCX0cxNBMGJLc9AxT0Tt2a9yaBq7NctcLLK4jLeVA at mail dot gmail dot com> <535FFA33 dot 90604 at lanl dot gov> <53600311 dot 7040805 at colorado dot edu> <53602290 dot 8020309 at lanl dot gov> <53629696 dot 7070907 at colorado dot edu> <5362D6E1 dot 5080605 at lanl dot gov> <5362F944 dot 9090408 at lanl dot gov>
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."