From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2484 invoked by alias); 1 Aug 2008 08:52:25 -0000 Received: (qmail 2475 invoked by uid 22791); 1 Aug 2008 08:52:24 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Aug 2008 08:51:55 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id D6041205F8 for ; Fri, 1 Aug 2008 10:51:52 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id B747C2059B for ; Fri, 1 Aug 2008 10:51:52 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sources.redhat.com Subject: Re: GDB to C++ issue: deletion Date: Fri, 01 Aug 2008 08:52:00 -0000 User-Agent: KMail/1.9.9 References: <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> In-Reply-To: <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808011054.24219.apoenitz@trolltech.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00001.txt.bz2 On Friday 01 August 2008 00:04:19 Paul Hilfinger wrote: > Alpar wrote: >=20 > > A good example for that was the debate on xfree vs. delete. One of the > > goals of STL standard containers is that using them the programmer will > > almost never has to use 'delete'. >=20 > This reminded me of an issue that I'd be curious to see discussed. > The STL container classes are certainly convenient for decreasing > memory leaks with little fuss, but they do so internally with > individual frees of allocated items. GDB currently does much of its > allocation using a region-based style (in the form of obstacks). This > reduces leakage at some expense in safety (although I have not seen > many dangling-pointer problems triggered premature obstack releases in > GDB). Allegedly, GDB's use of obstacks significantly speeds up > allocation and (of course) deletion. I have certainly seen programs > in which the need to free data structures individually adds > significant cost*. The STL container classes provide for allocators, > but I have no experience in how well they could be made to work in > duplicating GDB's current performance in this area. >=20 > I'd be interested in hearing the thoughts of the C++ lobby. 0. It's the wrong question ;-) It should not be "How to I translate the=20 code in lines 30 through 42 from C to C++?" but "The C code in lines 30 through 42 solves problem X. How would I solve X in C++?" (yes, custom allocators might be a solution to certain generic allocation performance problems, but the solution more often is something different.) 1. The problem of finding alternatives does not exist ;-) If someone feels - or, better, has proof - that good old C-style code provides the best=20 performance in some part of the code, and that part of the code is on the critical path, well, than just leave that piece of code as it is. Almost all C code is valid C++. 2. Even on this level, C++ might help to improve code readability and maintanance by using e.g. helper classes with destructors etc. that would translate to exactly the same machine code yet be more compact on the source side. 3. Thirdly: Micro-optimizations. They are nice to improve the performance of a piece of code _after_ one came to the conclusion that a certain approach is conceptually the best and uses already the theoretically best (or at least reasonable) data structures for the job. It's not uncommon to gain a factor of 2 to 10 just by doing micro-optimizations, gaining half of= a percent at a time. So they are a valuable tool in the tool chest. However, using them is a waste of resources if it's based on the wrong algorithm or data structures. Now, C code typically starts with linked lists as containers and improves a bit on that and then applies micro optimizations in the "user code" and than gets stuck at this level as refactoring of micro-optimized code is difficult especially when the optimizations are inlined in the user code and the algorithms/containers are tweaked away from "standard" implementations. With C++ one typically starts at least with the algorithm or container=20 that promises good scalability. That's easy, because "they are there". Switching later is also comparatively easy, sometimes it's even sufficient just to replace a single line to switch, say, from a std::list to a std::ve= ctor or such. So C++ code is much more lilkely to use the right container for the task, and using the wrong container typically costs a factor of "N" not 2 or 10. Incidentally, I think that the currently existing gdb (and other GNU core tools) nicely demonstrate the problem from a user's perspective: It does not scale well, and it has much worse performance than some competitors. Of course, multi-platform abstraction has an price, but using e.g. quadratic algorithms for an O(n) or O(n log n) task imply practical limits... see e.g= .=20 http://sourceware.org/ml/binutils/2004-01/msg00476.html for an example] Andr=E9=20 [1] Of course, every now and then a Guru level coder shows up, replaces one central trouble maker with something very cool, more efficient, even more hand-crafted, that happens to work well without being understood by aynone else. Then the Guru leaves, and the code becomes a "no go" area for mere mortals...