From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24002 invoked by alias); 2 May 2014 01:48:03 -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 23883 invoked by uid 89); 2 May 2014 01:47:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: proofpoint5.lanl.gov Received: from proofpoint5.lanl.gov (HELO proofpoint5.lanl.gov) (204.121.3.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 02 May 2014 01:47:51 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.14.5/8.14.5) with ESMTP id s421lnHJ010349 for ; Thu, 1 May 2014 19:47:49 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id DDD5D13673EE for ; Thu, 1 May 2014 19:47:48 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Received: from manticore.lanl.gov (manticore.lanl.gov [130.55.124.157]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 8E6AD13673DB for ; Thu, 1 May 2014 19:47:48 -0600 (MDT) Message-ID: <5362F944.9090408@lanl.gov> Date: Fri, 02 May 2014 01:48:00 -0000 From: Gerard Jungman 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: 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> In-Reply-To: <5362D6E1.5080605@lanl.gov> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-01_07:2014-05-01,2014-05-01,1970-01-01 signatures=0 X-SW-Source: 2014-q2/txt/msg00022.txt.bz2 Here is an example of the sort of thing that troubles me. http://stackoverflow.com/questions/15988836/better-memory-management-for-gsl-gsl-vector It is a reasonable discussion of exactly the sort of use case that keeps coming up. A couple independent issues are raised here. First is the question of allocation/deallocation overhead, which I think is the smaller of the issues, although it is important for people who need a lot of small vectors. This is the standard example justifying use of a custom pool allocator. Someone suggested using a single large gsl_block, effectively using that as a pool. This is not stupid, although it only works for some kinds of codes, where the allocation and hand-off of memory can be done in a central place, like at application startup time or something. At least that is how I think of that usage case. It appears that the OP was in one of the more de-centralized situations, where this would not work nicely. Ignore the associated comment about the "price you pay" when using a language without built-in garbage collection. Garbage collection (or lack thereof) is not the problem. But that is a separate discussion. See Stroustrup's comments about the correct use of the heap, in various talks lately. Second is the issue of value-semantics for containers. This is very tricky, possibly the deepest problem of all. Notice how the OP created a custom allocation function which returns a gsl_vector by value, not by pointer. That may or may not be the right choice for him, but it is interesting that he chose to do it that way. Value-semantics is probably the most important issue for container design, probably for several reasons. At the top of my list is the desire to get things onto the stack whenever possible. The fact that gsl_vector (the struct itself, not the data) is off the heap is an annoyance. And it's the kind of annoyance that may be no problem for some people and a show-stopper for others. It's too hard to tell in advance, since it is too hard to predict how modern hardware will treat your code. Stack-based computation helps, and linear traversal of data structures helps a lot, because the pre-fetcher will bring in the pages you need before you actually need them, as long as it can predict which ones are needed next. The heap tends to gum everything up on modern architectures, unless you are careful. And taking that kind of care may require taking over the alloc/free control from the standard library. So, the specific point raised by this value-semantics business, and its effect on heap confusion, is this: what to do about the fact that the GSL container structs are always off the heap? The final post in this short thread may hit the nail on the head. What he suggests is what I almost always do: use C++ containers and C++ code as much as possible, and bang the pointers into GSL functions when necessary. A bit sad.