From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36985 invoked by alias); 1 Nov 2015 21:00:21 -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 36910 invoked by uid 89); 1 Nov 2015 21:00:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: johndlamb.net Received: from srv210-24.hosting24.com (HELO johndlamb.net) (212.1.210.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 01 Nov 2015 21:00:13 +0000 Received: from host86-183-182-136.range86-183.btcentralplus.com ([86.183.182.136]:38522 helo=[192.168.1.64]) by srv48.hosting24.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1ZszjW-004G3i-LE; Sun, 01 Nov 2015 16:00:12 -0500 Subject: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release To: Patrick Alken , gsl-discuss@sourceware.org, Gerard Jungman References: <56293649.8010009@colorado.edu> <562BA530.7090508@johndlamb.net> <562E432D.9050002@colorado.edu> From: John D Lamb Message-ID: <56367D54.1040302@johndlamb.net> Date: Sun, 01 Nov 2015 21:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562E432D.9050002@colorado.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: srv48.hosting24.com: authenticated_id: j.d.lamb@johndlamb.net X-SW-Source: 2015-q4/txt/msg00000.txt.bz2 On 26/10/15 15:13, Patrick Alken wrote: >> Yes. I’d be happy to look at redesign of the GSL containers. What’s >> needed? >> > > There was a discussion on gsl-discuss some time back, see: > > https://www.sourceware.org/ml/gsl-discuss/2014-q2/ > > Gerard may have already done some work on this, or have some ideas on a > good starting point, so I suggest getting in touch with him too (cc'd). I’d forgotten the detail of that discussion. I can think of a way to change the gsl block/vector/matrix alloc functions to be more efficient. In essence it is a pool allocator. It would keep a record, for each power k of two up to some limit n, of the number of blocks allocated for sizes 2^k to 2^{k+1} together with a capacity (also a power of two) for blocks of that range. These would form linked lists of allocated and unallocated blocks. Given a request for a new block, if an unallocated one was available, it would be allocated. Otherwise the capacity would be doubled. When a block is freed, memory is only deallocated if no more than a quarter of capacity is used or if no blocks are used. This idea needs more input. I can’t think of a good way to create gsl_vectors and the like in stack memory. Of course, it is always possible to create a struct and initialise it. I also don’t know of a good, easy solution to the problem of constness. -- John D Lamb