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]

Re: GSL containers (switched sparse format to binary trees)



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."




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]