From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75856 invoked by alias); 3 Nov 2015 20:56:08 -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 75837 invoked by uid 89); 3 Nov 2015 20:56:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_50,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: proofpoint4.lanl.gov Received: from proofpoint4.lanl.gov (HELO proofpoint4.lanl.gov) (204.121.3.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 Nov 2015 20:56:05 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailgate4.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id tA3Ku22n020158 for ; Tue, 3 Nov 2015 13:56:02 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id C009DECA854 for ; Tue, 3 Nov 2015 13:56:02 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Received: from manticore.lanl.gov (manticore.lanl.gov [130.55.124.157]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 9A79FECA85A for ; Tue, 3 Nov 2015 13:56:02 -0700 (MST) Message-ID: <56391F62.2030103@lanl.gov> Date: Tue, 03 Nov 2015 20:56:00 -0000 From: Gerard Jungman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release References: <56293649.8010009@colorado.edu> <562BA530.7090508@johndlamb.net> <562E432D.9050002@colorado.edu> <56367D54.1040302@johndlamb.net> In-Reply-To: <56367D54.1040302@johndlamb.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21,1.0.33,0.0.0000 definitions=2015-11-03_10:2015-11-03,2015-11-03,1970-01-01 signatures=0 X-SW-Source: 2015-q4/txt/msg00001.txt.bz2 The problem with the GSL containers is that the allocation strategy is hard-wired into the implementation. Adding another allocation strategy is not the answer, it just adds to the problem. Put another way, the real problem is that the GSL interfaces are written in terms of gsl_vector and gsl_matrix objects, which forces clients to carry along the allocation baggage whenever they want to use a GSL interface. The interfaces (every function that currently takes a const gsl_vector * for example) should be re-written in terms of a view type which is independent of allocation strategies. A view type should be basically a thin wrapper over a pointer and a length for vectors. For multi-array objects it would be a thin wrapper over a pointer with an addressing/indexing interface. The current "view" types are brain-damaged because they stand the design on its head. This is because they were added as an afterthought to the existing heap-allocated vector/matrix objects, at the time when this was all being implemented. Badly done. At the implementation level, the other main problem is the way the types are "composed" using indirections. This is awful and leads to the multiple allocations and other heap-centric lossage that has been discussed recently. Both views and full-fledged containers should be composed in a value-centric and stack-friendly way. And preferably in a way that allows them to interoperate and keep const-correctness. I believe this is all possible. -- G. Jungman On 11/01/2015 02:00 PM, John D Lamb wrote: > 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. >