From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21545 invoked by alias); 31 Jan 2003 00:15:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21531 invoked from network); 31 Jan 2003 00:15:56 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by 172.16.49.205 with SMTP; 31 Jan 2003 00:15:56 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id h0V0Ftw16892 for ; Thu, 30 Jan 2003 16:15:55 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 30 Jan 2003 16:15:54 -0800 Received: from apple.com (mrs1.apple.com [17.201.24.248]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h0V0FsQ09483; Thu, 30 Jan 2003 16:15:54 -0800 (PST) Date: Fri, 31 Jan 2003 00:41:00 -0000 Subject: Re: GCC 3.3, GCC 3.4 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mike Stump , Benjamin Kosnik , gcc@gcc.gnu.org To: Neil Booth From: Mike Stump In-Reply-To: <20030130233824.GA14045@daikokuya.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg01699.txt.bz2 On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote: > I'm interested in improving the quality of GCC. Your statment above > indicates you're interested in pointing to a number and saying "look, > it's lower", regardless of what that means long-term. Hell, let's > not free anything at all and turn GC off altogether; GCC would be > faster > for 90% of files I imagine. Guess what? For smaller programs, it already does that! So, you are just describing status quo. > The improvements you're justifying are short-term gratification, but > make the genuine > improvements harder to develop, hard to find, and less easy to justify. > I don't think that's a good thing for the project long-term. Does this mean that we should immediately change the 8MB to 0MB? What I _am_ saying is, pretend the 8MB wasn't there. I want you to come up with the right number, the best number, the number you can say, this is the right number and I like it. Don't peek at what it was before, that is cheating. Tell me, what is the best number, and why? This is a serious question. Please support your number, so that we know that it wasn't just a wild ass guess, as certainly, we are better than that. Each magic constant needs to be defended and tweaked from time to time, that is just the nature of magic constants. I do agree with you, that it is better to not have magic constants, it is better to have well thought out algorithms in the compiler that don't need magic constants, but I'm pragmatic on this point I guess. Look at all the magic constants in the code already, it is littered with them. I don't think I've seen a compelling existence proof that it _is_ possible to get rid of them. I don't think we should disallow fixing of broken magic constants, just because it might be possible to write the code without them. If we can find a better magic constant, and get a 25% speed improvement, why should we sacrifice the improvement? If we must make the compiler perform worse to try and trick someone into substantially improving it, why is 100KB not a better magic constant than 8MB? Surely that would cause more pain than the current number?