From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16123 invoked by alias); 2 May 2014 15:02:50 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 16107 invoked by uid 89); 2 May 2014 15:02:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: ipmx6.colorado.edu Received: from ipmx6.colorado.edu (HELO ipmx6.colorado.edu) (128.138.128.246) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 May 2014 15:02:47 +0000 From: Patrick Alken Received: from bonanza.ngdc.noaa.gov ([140.172.179.41]) by smtp.colorado.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2014 09:02:46 -0600 Message-ID: <5363B395.5060101@colorado.edu> Date: Fri, 02 May 2014 15:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: GSL containers (switched sparse format to binary trees) References: <535DAFC0.8090402@colorado.edu> <535ED7A5.7020309@lanl.gov> <535EFCA5.8050807@colorado.edu> <535FFA33.90604@lanl.gov> <53600311.7040805@colorado.edu> <53602290.8020309@lanl.gov> <53629696.7070907@colorado.edu> <5362D6E1.5080605@lanl.gov> <5362F944.9090408@lanl.gov> <5362FB2A.7090608@lanl.gov> In-Reply-To: <5362FB2A.7090608@lanl.gov> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-q2/txt/msg00027.txt.bz2 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." > > >